Hi Damien, Damien Miller wrote on Tue, Aug 21, 2018 at 12:04:41PM +1000:> ok, djm@Thanks for checking, and thanks to Val and Michael for testing. I just committed the patch to OpenBSD, others will likely take care of merging it to -portable.> (I'd prefer the comment before the return statement, but up to you)Immediately before the return statement, it looked really confusing, like: /* ASCII on various systems ... blabla */ return UTF-8 ... blabla So i moved it up a few more lines and appended it to the existing comment, keeping the code concise and yet clearly explaining it. Yours, Ingo
Hello. Ingo Schwarze wrote in <20180821140545.GA11494 at athene.usta.de>: ... | /* ASCII on various systems ... blabla */ ... | return UTF-8 ... blabla | |So i moved it up a few more lines and appended it to the existing |comment, keeping the code concise and yet clearly explaining it. Don't be too serious about that, 'am being 100% sure you know, 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"}; --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
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