libiconv doesn't support "UTF8" alias

[kyz (Stuart Caie)]

I'd like libiconv to support the "UTF8" alias for the UTF-8 charset in iconv_open()

• as glibc supports
• as BSDs support
• as macOS supports natively
• as Cygwin patches libiconv to support "for better compatibility with glibc" (see ​https://cygwin.com/ml/cygwin/2015-02/msg00482.html and ​https://github.com/cygwinports/libiconv/blob/master/1.14-aliases.patch)
• as libiconv < 1.13 supported

Background: with libiconv 1.13, the maintainers decided to limit various aliases to specific OSes (see 2008-04-06 changelog entries), and they decided "UTF8" was an HPUX specific alias (I would disagree), so libiconv >= 1.13 doesn't recognise "UTF8" as an alias except when compiled on HPUX.

My software, cabextract, used "UTF8" because it was the most portable name for the UTF-8 charset amongst iconv() implementations. For example, newlib does not support libiconv's preferred "UTF-8", only "UTF8" or "UTF_8", so "UTF8" is the common denominator.

"UTF8" works on all common platforms... but not Macports. "UTF-8" works on all common platforms, but not systems using newlib.

I've had to change my software just for Macports, now it tries out multiple names for the same charset until one works. This is not normal. It would be better if Macports changed to support "UTF8" as an alias.

Please add a patch to libiconv that uncomments line 61 of lib/encodings.def

[ryandesign (Ryan Carsten Schmidt)]

I remember us talking about this in email before, so thanks for following up on it.

As you point out, it's the developers of libiconv who chose to do this, so it's not a MacPorts-specific problem. The problem would affect anyone who uses libiconv on macOS, whether they get it from MacPorts, Homebrew, Fink, or compile it themselves. I don't feel that each package management system should have to forever maintain a patch for this; I feel that the upstream libiconv source code is the correct place to make the change. Have you already discussed it with the developers of libiconv? If not, that's what I'd suggest.

[kyz (Stuart Caie)]

I have written to the developers of libiconv (today, at the same time as this request), but I haven't heard back from them yet. I'll let you know what they say.

Even if they agree, it may be quite some time before the change becomes officially available. libiconv 1.15 was released about 6 years after 1.14; what if libiconv 1.16 is released in 2024? In such circumstances, would it be OK to maintain a patch until the next libiconv release?

[ryandesign (Ryan Carsten Schmidt)]

Of course, and I'll probably make the change regardless of whether they do, I just prefer whenever possible to push changes back to the upstream developers so that as many users as possible can benefit and so that I don't have to maintain lots of patches.

[ryandesign (Ryan Carsten Schmidt)]

Replying to kyz:

I have written to the developers of libiconv

Have they responded?

[chrstphrchvz (Christopher Chavez)]

Replying to ryandesign:

Replying to kyz:

I have written to the developers of libiconv

Have they responded?

Yes, and the request was for the UTF8 alias was rejected: ​https://lists.gnu.org/archive/html/bug-gnu-libiconv/2019-01/threads.html#00000.

[ryandesign (Ryan Carsten Schmidt)]

Thanks for the link. The developer has explained in his mailing list response why he doesn't want to add the alias. I'm sure he understands this stuff better than I do, and I don't want to second-guess him, so I won't make the change in MacPorts libiconv.