On Sun, Jan 29, 2012 at 07:47:26PM -0800, Walter Bright wrote: > 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.
I can just see all those string malloc()'s screaming in pain as buffer overflows trample them to their miserable deaths: void f(int length) { char *p = (char *)malloc(length); /* yikes! */ int i; for (i=0; i < length; i++) { /* do something with p[i] ... */ } ... } Is there an actual, real, working C compiler that has char sized as anything but 8 bits?? This one thing alone would kill, oh, 99% of all C code? T -- Klein bottle for rent ... inquire within. -- Stephen Mulraney