Path: utzoo!mnetor!uunet!husc6!necntc!ima!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: Long Chars
Message-ID: <2959@haddock.ISC.COM>
Date: 15 Mar 88 02:16:02 GMT
References: <12341@brl-adm.ARPA>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 18

In article <12341@brl-adm.ARPA> TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU writes:
>[Until "long char" gets added, probably in the 2nd standard, try]
>typedef short LONG_CHAR; [and add a bunch of library functions].

Something equivalent is in fact in the current standard; they called it
wchar_t (wide character type).  I've only just gotten hold of a dpANS recent
enough to include this, and haven't finished reading it, but my impression is
that only the type, the corresponding constants (L'x' for wchar_t, L"x" for
wchar_t[]), and a few utility functions are being added for this standard.

The real problem is that "char" has been inappropriately overloaded.  We need
to distinguish between a text character (wchar_t or long char), a small
integer (short short int), and a quantum of memory (byte_t or short char).
Ideally, all three of these should have names other than "char", and the type
"char" should be deprecated.  Unfortunately, there's so much inertia to
overcome that this will probably never be fixed in C.  Fix it in "D"...

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint