cent and ucent?

[H. S. Teoh]

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