🚀 go-pugleaf

In article <1992Dec15.182228.23669@taumet.com> steve@taumet.com (Steve Clamage) writes:
>gjb@fig.citib.com (Greg Brail) writes:
>
>>The most recent Sun ANSI C compiler (Sparc Works 2.0.1) supports a 64-bit
>>integer type called "long long". Since this type is only available with
>>the compiler in "strict ANSI" mode, I suppose it is part of the proposed
>>ANSI C standard. Is this true?
>The locution "long long" violates a constraint in section 3.5.2 of the
>ANSI Standard, and must be diagnosed as an error by a conforming
>implementation.  If the "long long" extension is available only in
>"strict ANSI" mode, they got it backwards.  I would expect such an
>extension to be available only when "strict" mode is disabled.

Sorry. I just looked at the man page for the new compiler, which says 
"long long" is available in "ANSI plus Sun extensions" mode, but disabled
in "strict ANSI" mode. So Sun didn't get it backwards.

>>But more importantly, are there any existing proposals to add "long long"
>>to the C++ standard? Such a data type would be quite useful. Are there
>>any existing C++ compilers that support, or plan to support this type?
>
>The next C standard will probably support an integer type longer than
>type long.  The C++ Committee has no proposals that I know of for
>adding such a type.  When it is added to C, it will certainly be
>added to C++.  If the ANSI C numerical extensions group decides on a
>longer integer type and it looks likely to be included in C, I would
>expect the C++ Committee to adopt it.  It is thus possible that C++
>will have it officially before C, if only due to timing.

Thanks for the help.

				greg
-- 
Greg Brail ------------------ Citibank -------------------- gjb@fig.citib.com
lose (lOOz) v. 1. a. To be unable to find; mislay. b. To incur the 
deprivation of, as by negligence or accident. 2. To be unable to maintain,
sustain, or keep. 3. The most commonly misspelled word on Usenet.