Usage of iconv()

[Magnus Ihse Bursie]

That is a good question. libiconv is used only on macOS and AIX, for a 
few libraries, as you say. I just tried removing -liconv from the macOS 
dependencies and recompiled, just to see what would happen. There were 
three instances for macOS: libsplashscreen, libjdwp and libinstrument.

Out of these, libinstrument compiled and linked fine without the -liconv 
argument. It looks like iconv is referenced in 
unix/.../EncodingSupport_md.c, but otoh it looks like it is as much (or 
as little) referenced on macOS as on linux (where we never have linked 
with -liconv) so it is perhaps just dead code. I did not study it in 
detail. The code looks very much duplicated from libjdwp.

The other two actually failed linking, so they do use libiconv.

libsplashscreen uses it in splashscreen_sys.m, where it is used to 
convert the jar file name.

libjdwp uses it in utf_util.c, where it is used to convert file name and 
command lines, iiuc.

It is likely that we have similar (but better) ways to convert charsets 
elsewhere in our libraries that can be used instead of libiconv. I guess 
these are not the only two places where a filename must be converted 
from the platform charset to UTF8.

/Magnus

On 2024-04-23 14:11, Bernd Eckenfels wrote:
> Du to a glibc security alert about a charset in iconv() I checked OpenJDK (since I was quite sure encoding is handled in JCL), however there are a few utilities (related to libinstrument and splash Screens) which use iconv.
>
> If I see it correctly it’s mostly used for utf8 so it should not expose this particular globe weakness, but I still wonder if that dependency is needed. For some platforms like AIX it even drags on an additional library dependency. (Not to mention different charger tables and especially ugly locale dependencies for containers).
>
> Gruß
> Bernd
> —
> https://bernd.eckenfels.net