Undelivered mail

[MAILER%ALASKA.BITNET at CUNYVM.CUNY.EDU]

Subject:  Long Chars

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C at BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 0538
          for SXJVK at ALASKA; Sun, 13 Mar 88 01:06 AST
Received: by UWAVM (Mailer X1.25) id 6525; Sun, 13 Mar 88 02:05:53 PST
Date:         Sat, 12 Mar 88 22:11:00 EST
Reply-To:     Info-C at BRL.ARPA
Sender:       Info-C List <INFO-C at NDSUVM1>
From:         TLIMONCE%DREW.BITNET at CUNYVM.CUNY.EDU
Subject:      Long Chars
Comments: To: info-c at BRL.ARPA
To:           Vic Kapella <SXJVK at ALASKA>

(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 at drew.BITNET
    Disclaimer: These are my views, not my employer or Drew Univesity
--------------------------------------------------------------------------