From: dje@sspiff.UUCP (Doug Evans)
Subject: Re: PLEASE don't use "long long" for 64 bits + answer to letter
Organization: Edmonton, Alberta
Date: Wed, 08 Apr 1992 16:56:40 GMT
Followup-To: comp.lang.c

I've cross posted this to c.s.c because I'm interested in the hearing the
opinions of the folks there (if they choose to). Followups to c.l.c.
(Actually, the original thread had them cross posted to both, but when
composing my earlier message, I couldn't cross post).

murphy@mips.com (Mike Murphy) writes:
>Let me throw the question back at you:
>what real advantage is there to using __long int
>(note the use of two underscores when lower-case) 
>or __int64 compared to long long?

The advantages:
- when the time comes, ANSI can do something different if desired/necessary
  (the C namespace and syntax hasn't become "violated")
- when the time comes, if other vendors go with something different,
  as long as those vendors stick to their private namespace, ANSI can
  bring them all back in sync with little to no pain.

(These two may be just different ways of saying the same thing).

>No new type name that you pick will be compilable 
>by a strict ANSI compiler, so you should use typedefs
>and ifdefs for all of these suggestions.  
>ANY extension is bothersome if the standard adopts a 
>different convention.

Indeed. But, if I may try to paraphrase everyone's objections (and please
flame me if I get it wrong), it's tricky business adding stuff to
non-experimental languages with huge installed bases (and lots of vendors!).
If tight controls are not maintained, down the road you may end up with an
adhoc mess (I'm not saying this will happen, I'm just hyperbolizing (sp?)).
Asking vendors to go with __int64 (or whatever) is more of a guarantee that we
won't end up with a mess (to the C language proper) than going with
"long long". I don't know, but seems to me that without ANSI's stamp on it, the
probability is too great for our comfort that some vendor will come along and
do something different. Once Pandora's box is open ...

And, I can't help but wonder if "long long" is a little short-sighted
(this is just a personal opinion). Down the road there will be
"long long long [int]", and I wonder if that's really the best way to go.

Although, having stared at it long long :-) enough in the past few weeks, I
wonder if there is any solution that won't have warts. Given that we are
already using words to distinguish different sizes, (as opposed to
numbers/symbols and syntax) the "go with the flow" (or "when in Rome ...",
or "Stick with the program", or ... :-) solution would seem to be to continue
to use words.

Still, if one accepts "long long" what about "short short"? The keyword "long"
doesn't have a special significance that "short" doesn't (please, no "long
double" stuff. I'm talking about ints here). One can envision a future with 5
or 6 word sizes, int being somewhere in the middle, and there being:

short short [int], short [int], int, long [int], long long [int].

Triple yuck! Seems to me that as a computer language, this is getting real ugly
real fast.

>Keep in mind that long long doesn't add any new keywords;
>it just repeats the keyword "long".

Indeed. When the time comes, it is certainly a candidate. There are
certainly others though.
-- 
Doug Evans                   |
..!{canada,uunet}!sspiff!dje | Vancouver 11, Calgary 0
dje@sspiff.UUCP (prefered!)  | There is no joy in Cowtown.
dje@ersys.edmonton.ab.ca     | But how 'bout those Canucks, eh?
Newsgroups: comp.lang.c