Hi Steffen,
Steffen Nurpmeso wrote on Tue, Aug 21, 2018 at 04:57:30PM +0200:
> Don't be too serious about that, 'am being 100% sure you know,
I did not.
> but having been stung by "concise" (and because my MUA had to
> implement n_iconv_name_is_ascii()) i want to point out that the
> IANA character sets define more aliases for US-ASCII, already in
> RFC 1345. Here in reverse MIME preference order:
>
> static char const * const names[] = {"csASCII", "cp367", "IBM367",
> "us", "ISO646-US", "ISO_646.irv:1991", "ANSI_X3.4-1986",
> "iso-ir-6", "ANSI_X3.4-1968", "ASCII", "US-ASCII"};
But as far as i know, nothing requires nl_langinfo(CODESET) to
adhere to RFC 1345, and as a matter of fact, on some systems,
it does not (Solaris, NetBSD). So even including the full list
you are providing above would be insufficient.
On the other hand, using the full list *in addition* to what's
actually required provides no benefit, but poses gratuitous
additional risk of misidentification, in particular with names
as generic as "us". We were just told that AIX returns en_US
for ASCII and EN_US for UTF-8 (or was it the other way round?
That's hard to remember). Who knows what other systems out
there might return "us" for?
Given the lack of standardization of nl_langinfo(3), adding the
return values that actually matter in practice, and nothing else,
seems like the way to go, in my opinion.
Yours,
Ingo
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
