Re: unicode (char as abstract data type)

Clayton Weaver (cgweav@eskimo.com)
Fri, 17 Apr 1998 08:02:29 -0700 (PDT)

The needed breakthrough is to forget the C language signed/unsigned char
as having something to do with natural language, and see it as merely
a byte-wide int, and the name of the data type as some archaic baggage
from the pdp-11. Characters in the context of language processing code
need to be an abstract data type. If you can squeeze it into 2 bytes
internally and switch unicode planes on the fly, great, that's efficient.
But that should be an internal implementation that application programmers
don't really have to think about, like the internal representation of
Pascal ints.

But functions that take char * as an arg or return same don't have a
byte-to-char mapping, even if they still work (it doesn't matter which
byte of a wide character differs in a strcmp(), only whether all bytes
match; but if you need to know the magnitude of the difference if they
don't match, now you need a whole different function than what a million
C/C++ programmers already know).

Programmers who like C for it's simplicity are going to find this
irritating, this isn't "portable assembler" any more. Familiar string
idioms are going to be mostly worthless. It may help reduce the chaos
to use lclint's abstract interface annotation and checking on wide char
string code.

Regards, Clayton Weaver cgweav@eskimo.com (Seattle)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu