Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!uunet!zephyr.ens.tek.com!tektronix!reed!intelhf!ichips!iWarp.intel.com!intelisc!hays@ssd.intel.com From: hays@ssd.intel.com (Kirk Hays) Newsgroups: comp.lang.c Subject: Summary of responses to prior art on "long long" type Message-ID: <1417@ssdintel.isc.intel.com> Date: 19 Jun 91 15:34:20 GMT Sender: news@isc.intel.com Reply-To: hays@ssd.intel.com (Kirk Hays) Organization: Intel Supercomputer Systems Division Lines: 150 Nntp-Posting-Host: roadkill Here is the summary of responses to my question on prior art on the "long long" type, mentioned in the ANSI standard. Everyone seems to be in step but Compass [Compass take note! Your printf/scanf formats for "long long" appears to be in disagreement with everyone else's convention, as well as the ANSI standard, section 4.9.6.1] =================================================== >I am looking for prior art in the consistent implementation of the "long long" >data type. > >In our compiler, we currently support the following types and sizes: > >char - 8 bits >short - 16 bits >int - 32 bits >long - 32 bits > >we want to add: > >long long - 64 bits. > >I am looking for companies that have already added "long long" to their >datatypes, and their solutions to: > >- suffixes for constants >- format designator(s) for *printf and *scanf families The answer that everybody agrees on is: LL (upper or lower case) for constants %lld for printf/scanf. This is what gcc does, what convex does, and what we (MIPS) are in the process of doing. Also, there was recently a meeting between MIPS, Sun, IBM, ATT and HaL about 64-bit conventions, and we all agreed about the use of long long and associated syntax (where we didn't agree is what happens when you move to 64-bit addresses). I'm not sure if there will be any future meetings of that group, but if you are interested in participating you should contact [name] who organized the meeting. =================================================== how about a standard suffix for unsigned long long constants - is it UL or UU or LU Check your ANSI manual (I assume this will ANSI-compliant?). U is already used for unsigned, L for long, together they mean unsigned long; when you combine u with ll, you get unsigned long long. and likewise for printf/scanf formats? Again, the language takes care of this; ll applies like l to the following conversion specifier. =================================================== I don't know about any prior art, but if you look in the archives of comp.lang.c beginning in April, you will find quite a bit of commentary about that very subject. =================================================== Check out GNU CC, I think it already does a "long long" integer type. =================================================== Our compiler [Convex] has supported long long for at least the last three years. > >- suffixes for constants If a constant ends in LL or ll the compiler will take it as a long long int. Also if an constant integral constant is greater then LONG_MAX or ULONG_MAX, the constant type is promoted to long long or unsigned long long, respectively. >- format designator(s) for *printf and *scanf families LL and ll are also used by scanf and printf family of routines to indicate that the length of the argument to interpert is a long long int. I also believe that gcc now support a long long type. How the handle this I don't know. cheers =================================================== GNU CC has long long. It uses LL for constants. There is no GNU C library yet; I don't know what they will do there. =================================================== The Compass C compiler supports 64-bit integer quantities. The salient language features are: type specifier: long long constant suffix: LL and ULL format designators: %Ld, %Lu, etc. =================================================== Look at gcc. I had some peripheral exprience with the long long type, mostly to the extent that "... don't worry about unless you plan on using long longs"... etc. =================================================== GCC implements "long long" (and might have invented it). The source is available from prep.ai.mit.edu, directory pub/gnu, file gcc.tar.Z Since GCC usually uses the host's existing C libraries, I don't know how they could have added a printf format, but there might be something they use for constants. (I don't use GCC myself, just passing on info I picked up in the wind.) =================================================== The most popular one is probably the GNU C compiler. It doesn't come with a C library, at least not that I've seen, so they didn't address printf/scanf issues. I believe Convex also uses long long. =================================================== Get the Convex compiler manuals. =================================================== I think this point has been made already, but I would make sure that all of {char, short, int, long} refer to distinct types before contemplating the invention of a fifth type. In other words, use "plain" long as your 64-bit type. I am well aware of the prevalence of badly-written code which might be "broken" (even though it's already broken) by such an approach. =================================================== -- Kirk Hays - NRA Life. Message for Timothy Fay - "Do not eat/wear/exploit things you will not kill."