Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!adm!TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU
From: TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU
Newsgroups: comp.lang.c
Subject: Long Chars
Message-ID: <12341@brl-adm.ARPA>
Date: 13 Mar 88 03:41:29 GMT
Sender: news@brl-adm.ARPA
Lines: 34

(This discussion is looking for a good pun... like "lawn chairs"?  No... I
said GOOD pun.)

The "short char vs char" problem can't be solved very easily.  Why not a
"long char".  That wouldn't break much code now, would it?  Now I'm not
demanding that it goes into v1.0 of the standard but maybe we can look at
this for the next "congress".

For now, if you want to make some progress, try to get one of the biggies
(like MS) to add it as an extension.  You can tell them that they'll hit
on the "multi-nation/multi-language vendor market" with it.

Of course, in my programming I don't have a use for it, but if you do, try

typedef short LONG_CHAR;
or
typedef char LONG_CHAR[2];
(Hmmm... I like the former)

and then you can implement a lstrcmp() and a lstrcpy() and an assortment
of routines like that.  Then when you're done, those can be re-used in all
your programs.

When it get's suggested to ANSI C II (or whatever it'll be called) you'll
be there to warn us about implementation difficulties and ideas.  And when
it gets passed you can do a search-and-replace from "LONG_CHAR" to "long
char"

"And there was much rejoicing" -- Monty Python


Tom Limoncelli | Drew U/Box 1060/Madison NJ 07940 | tlimonce@drew.BITNET
    Disclaimer: These are my views, not my employer or Drew Univesity
--------------------------------------------------------------------------