Messages in this thread | | | Date | Fri, 17 Apr 1998 08:02:29 -0700 (PDT) | From | Clayton Weaver <> | Subject | Re: unicode (char as abstract data type) |
| |
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
| |