On 1/29/2012 6:46 PM, H. S. Teoh wrote:
Not to mention the totally non-commital way the specs were written about wchar_t: it *could* be UTF-16, or it *could* be UTF-32, or it *could* be a non-unicode encoding, we don't guarantee anything. Oh, you want Unicode, right? Well for that you need to consult your OS-specific documentation on how to set up 15 different environment variables, all of which have non-commital descriptions, and any of which may or may not switch the system into/out of unicode mode. Oh, you want a function to guarantee unicode mode? We're sorry, that's not our department.
I've had people tell me this was an advantage because there are some chips where chars, shorts, ints, and wchars are all 32 bits. Isn't it awesome that the C standard supports that?
The only problem with that is that while the C standard supports it, I can't think of a single C program that would work on such a system without a major, and I mean major, rewrite. It's a useless facet of the standard.
