long long vs. long? 
Author Message
 long long vs. long?

Okay, I've seen too many passing references to 'long long' so I have to
bite:

...it's not in K&R and not in the Plauger, so where did it come from?
...will it be a standard?  likely to be?  or just an extension?
...what is its formal definition?  How lon-- er, wide is it?
...why is it necessary?  Why can't just 'long' suffice?

BTW, I'm working on an Alpha under Digital Unix, so to me, int is 4
bytes, long is 8 bytes, so, long long is... redundant.  On the Suns I
see int is 4, long long is 8, and long is 4- redunant.  What gives?  Why
the redundancy?

So, I'm guessing it is/will be:
  sizeof(long long) >= sizeof(long) >= sizeof(int)

Or is this a "too many people assumed sizeof(int) == sizeof(long) so it
can't change now" sorf of thing?

Scott



Fri, 02 Feb 2001 03:00:00 GMT  
 long long vs. long?

Quote:

> Okay, I've seen too many passing references to 'long long' so I have to
> bite:

> ...it's not in K&R and not in the Plauger, so where did it come from?
> ...will it be a standard?  likely to be?  or just an extension?

It's a very popular extension and is slated to be included in the next
revision of the standard.

Quote:
> ...what is its formal definition?  How lon-- er, wide is it?

At least 64-bits, IIRC.

Quote:
> ...why is it necessary?  Why can't just 'long' suffice?

> BTW, I'm working on an Alpha under Digital Unix, so to me, int is 4
> bytes, long is 8 bytes, so, long long is... redundant.  On the Suns I
> see int is 4, long long is 8, and long is 4- redunant.  What gives?  Why
> the redundancy?

The sizes just happen to be redundant in your implementation.
Similarly, in most modern 32-bit compilers, int and long are the same
size (32 bits).  The redundancies don't exist in the standard, just in
its implementations.

Quote:
> So, I'm guessing it is/will be:
>   sizeof(long long) >= sizeof(long) >= sizeof(int)

> Or is this a "too many people assumed sizeof(int) == sizeof(long) so it
> can't change now" sorf of thing?

It's more of a, "too many people assumed sizeof(long) == 4" thing (on
8-bit byte machines).  It's only necessary because existing practice
practically demands that long be 4 bytes wide, even if the standard
never guaranteed it.

If you're {*filter*} on long long then I'm guessing you haven't heard about
int32_t, int_least32_t, int_fast32_t, intptr_t, or intmax_t.  The
horrors!

--

I believe we can change anything.
I believe in my dream.
    - Joe Satriani



Fri, 02 Feb 2001 03:00:00 GMT  
 long long vs. long?

   Okay, I've seen too many passing references to 'long long' so I have to
   bite:

   ...it's not in K&R and not in the Plauger, so where did it come from?

It's in GNU C, but I doubt whether that's where it orginated.

   ...will it be a standard?  likely to be?  or just an extension?

I believe that it is in C9x.

   ...what is its formal definition?  How lon-- er, wide is it?

It is at least as wide as a long.  On 32-bit-word machines it's 64 bits.

   ...why is it necessary?  Why can't just 'long' suffice?

   BTW, I'm working on an Alpha under Digital Unix, so to me, int is 4
   bytes, long is 8 bytes, so, long long is... redundant.

It's not 16 bytes?                                                        
                                                           On the Suns I
   see int is 4, long long is 8, and long is 4- redunant.  What gives?  Why
   the redundancy?

Because lots of software assumes sizeof (int) == sizeof (long)?

   So, I'm guessing it is/will be:
     sizeof(long long) >= sizeof(long) >= sizeof(int)

   Or is this a "too many people assumed sizeof(int) == sizeof(long) so it
   can't change now" sorf of thing?

I think so.
--
(supporter of the campaign for grumpiness where grumpiness is due in c.l.c)

Please: do not email me copies of your posts to comp.lang.c
        do not ask me C questions via email; post them instead



Fri, 02 Feb 2001 03:00:00 GMT  
 long long vs. long?


Quote:
> Okay, I've seen too many passing references to 'long long' so I have to
> bite:

Just to reiterate for anyone who didn't already know: `long long' is not
valid in ISO C (9899:1990), and so is (strictly speaking) off-topic here.

Quote:
> ...it's not in K&R and not in the Plauger, so where did it come from?

Good question.  I know that several Unix compilers have it -- notably GNU
gcc and the native Digital Unix cc.  IIRC, it was a V8 Unix cc thing, but I
hope someone will either elaborate on that statement or correct it.

Quote:
> ...will it be a standard?  likely to be?  or just an extension?

It is in the public draft of C9x and will likely be specified in the final
C9x.

Quote:
> ...what is its formal definition?  How lon-- er, wide is it?

At least 64 bits.  (Actually, it's defined in terms of minimum conforming
limits for LONG_LONG_MIN and LONG_LONG_MAX, but the effect is the same.)

Quote:
> ...why is it necessary?  Why can't just 'long' suffice?

This is flame bait, especially over in comp.std.c.  My personal view is that
an extended arithmetic type is useful, and long long seems a reasonable
enough name for it.  But allowing size_t, ptrdiff_t etc to be long long will
break code that is maximally conforming under C89; that's not a good thing
in my book.

Quote:
> BTW, I'm working on an Alpha under Digital Unix, so to me, int is 4
> bytes, long is 8 bytes, so, long long is... redundant.

Yes.

Quote:
> On the Suns I see int is 4, long long is 8, and long is 4- redunant.  What
> gives?  Why the redundancy?

> Or is this a "too many people assumed sizeof(int) == sizeof(long) so it
> can't change now" sorf of thing?

That's the argument.  I don't hold to it -- there are still several
implementations around which have 16-bit int and 32-bit long.  IMHO, 64-bit
implementations should follow the lead of Digital and GNU and simply use
16-bit short, 32-bit int, 64-bit long.

--



Sat, 03 Feb 2001 03:00:00 GMT  
 long long vs. long?

Quote:
>...why is it necessary?  Why can't just 'long' suffice?

Have you looked at WinAPI calls, where numbers with more than 32 bits are built
as a struct with 2 parts, typedef'd LONG and DWORD?  Some of us want to cast
that to a double or long double, which long long permits in the obvious way.
Tim Prince



Sat, 03 Feb 2001 03:00:00 GMT  
 long long vs. long?


|> Okay, I've seen too many passing references to 'long long' so
|> I have to bite:
|>
|> ...it's not in K&R and not in the Plauger, so where did it come from?
|> ...will it be a standard?  likely to be?  or just an extension?
|> ...what is its formal definition?  How lon-- er, wide is it?
|> ...why is it necessary?  Why can't just 'long' suffice?
|>
|> BTW, I'm working on an Alpha under Digital Unix, so to me, int
|> is 4 bytes, long is 8 bytes, so, long long is... redundant.  

From the standpoint of a language purist, I think that we would all
agree that this strategy probably makes the most sense with regards
to the language.  It takes the facilities that the language offers
and adapts them to the environment in a way that makes sense.  It
ignores some of the more grim realities imposed by the current large
base of existing C code.  However, since the Alpha is by and large
still relatively "new", some of these realities do not affect it as
much (although it is certainly still affected to some degree.)

|> On the Suns I see int is 4, long long is 8, and long is 4-
|> redunant.  What gives?  Why the redundancy?

The redundancy arises out of one of the most pressing goals of the
language standardization committee: to codify existing practice,
and to avoid introducing changes that "break" large bodies of
existing C code.  In some instances, this has required the language
to embrace some unsavory additions in the interest of keeping some
semblance of order among the billions of lines of existing C code.
These language features are often not pretty, but represent long-
debated compromises that attempt to strike a balance between
preserving the platform-independent spirit of the language while
still pacifying the voluminous amounts of existing legacy code
(and existing legacy *data files* associated with said code.)

Enter "long long."  Currently, it is not a standard C type, but it
most likely *will* be in the upcoming revision of the C language,
which is tentatively called C9X.  The main purpose of this new
type is to standardize an integral type that can be used to store
values that are (at least) 64 bits wide.  Yes, the current
language definition allows plain old "long" to serve this purpose
quite well, yet many implementors are reluctant to do so.  Compiler
vendors are only too willing to keep their customers happy, and
that interest is not served by releasing new versions of their
product that severely break their customers' systems.  Customers
will not want to be told that their code made unsafe assumptions.
They will want a C implementation that will keep them up and
running.  If they receive a sermon instead of a "satisfactory"
compiler, chances are they will go elsewhere with their business.

Let it hereby be known that "long long" is a hack; it's a language
addition that would have been (currently) laughed out of the
committee meeting if we all lived in a perfect world.  However, the
obvious and unfortunate truth is that we *don't* live in a perfect
world, or even a world sufficiently advanced to make "long long" a
useless and offensive construct.  If we did live in such a world,
then nobody would be faced with the prospect of maintaining code
which relies on hardwired assumptions about the sizes of integral
types.  Nobody would have to worry about babysitting a multimillion
LOC system that can only reasonably function in an environment
where "long" is 32 bits.  But this world is a fantasy.

I don't particularly care much for "long long."  But like most
other hacks, it has not been introduced because of its elegance or
beauty.  It's been introduced because there is a legitimate, real-
world hole to fill, and by most accounts, it's probably the best
solution to a particularly unfortunate problem.  With that in mind,
I'd guess that most of the C programmers who are opposed to it at
least acknowledge why it is necessary, and can live with it.

A popular pastime in comp.lang.c is to sit atop, as one poster
whose name escapes me now put it, an "ivory tower of portability",
haughtily condemning those who dare to post any kind of a platform
specific or otherwise nonstandard piece of code in the newsgroup.
Code which assumes that "long" is a specific, perpetual 32-bit size
would likely be prime fodder for ridicule here.  And the truth,
strictly speaking, is that we would be justified in ridiculing the
assumption, because there has never been a hard-and-fast guarantee
that "long" will be a certain size .. both before the language was
standardized and since.

But while it's easy to sit atop this tower and pass judgement,
saying "The 64-bit type on 64-bit machines shall be 'long', and
any code that breaks as a result will getting what it deserves,"
the truth is that it's hard to say this with a clear conscience.
There are a couple of reasons.  The first is that there was a
time, and it was really not so long ago, when the assumption that
"long" was 32 bits *was* reasonably valid, even though it was not
expressed in so many words in some standards document.  Sure, it
may have been somewhat shortsighted, but the assumption was far
from ridiculous.

The second is a bit more practical:  Sermonizing and passing
judgement on a large body of existing code will not make the
problem magically vanish.  We have to play the cards we're dealt,
and in this case the existing code base has the upper hand.  

I'll see your 32 bits and raise you a "long long."

|> So, I'm guessing it is/will be:
|>   sizeof(long long) >= sizeof(long) >= sizeof(int)
|>
|> Or is this a "too many people assumed sizeof(int) == sizeof(long)
|> so it can't change now" sorf of thing?

A more appropriate way to put it might be "too many people assumed
short was 16 bits and long was 32 bits and int was either of the
above."  This was, of course, an unfortunate assumption.  This was
a particularly popular claim when writing C code that had to work
and play together with fortran code on multiple platforms.

But again, I'm not trying to lay blame or to speak negatively of
those of us who fell victim to the assumption.  The vast majority
of the regulars of comp.lang.c have been doing C development for
quite some time, and I submit that many of them (myself included)
have written code based on this very assumption.  Now, the language
has been standardized for nearly a decade, and we've had plenty of
time to study the language definition and reflect on the past.
We're a bit older and wiser, but that in itself will not make the
problem go away.  If it takes "long long" to address the problem,
then it must be accepted, ugliness notwithstanding.

Regards,

(PS:  You might want to search DejaNews for some of the articles
that John Mashey has written on this subject; in particular, the
articles that address the different strategies that vendors can
use with regards to integral type sizes on 64-bit systems.  They
can shed far more light on this topic than I am able to.)

--
Chris Engebretson - Raytheon STX Corporation | Ph#: (605)594-6829
USGS EROS Data Center, Sioux Falls, SD 57198 | Fax: (605)594-6940

Opinions are not those of  Raytheon Systems Company  or the USGS.



Sat, 03 Feb 2001 03:00:00 GMT  
 long long vs. long?

Quote:

> Or is this a "too many people assumed sizeof(int) == sizeof(long) so it
> can't change now" sorf of thing?

It's more a case of people want to be able to write 64 bit code even
on 32 bit platforms (just like people wanted to be able to write 32 bit
code on 16 bit platforms -- that's where long came from), compatibility
between 32 and 64 bit platforms, mixed platforms (32 bit OS on 64 bit
machine or vice versa), and efficiency (32 bit code tends to be smaller
and faster than 64 bit code, even on a 64 bit platform).

-Larry Jones

I kind of resent the manufacturer's implicit assumption
that this would amuse me. -- Calvin



Sat, 03 Feb 2001 03:00:00 GMT  
 long long vs. long?

Quote:

> Okay, I've seen too many passing references to 'long long' so I have to
> bite:

> ...it's not in K&R and not in the Plauger, so where did it come from?
> ...will it be a standard?  likely to be?  or just an extension?
> ...what is its formal definition?  How lon-- er, wide is it?
> ...why is it necessary?  Why can't just 'long' suffice?

> BTW, I'm working on an Alpha under Digital Unix, so to me, int is 4
> bytes, long is 8 bytes, so, long long is... redundant.  On the Suns I
> see int is 4, long long is 8, and long is 4- redunant.  What gives?  Why
> the redundancy?

> So, I'm guessing it is/will be:
>   sizeof(long long) >= sizeof(long) >= sizeof(int)

> Or is this a "too many people assumed sizeof(int) == sizeof(long) so it
> can't change now" sorf of thing?

    The only "rule" is that each type is "at least as big" as what comes
before it.

    int is at least as big as char
    long is at least as big as int
    long long is at least as big as long
    so on, and so forth...

    As long as the hardware maintains this relationship, they're free to
do whatever they want.



Sun, 04 Feb 2001 03:00:00 GMT  
 long long vs. long?


...

Quote:
>> So, I'm guessing it is/will be:
>>   sizeof(long long) >= sizeof(long) >= sizeof(int)

That isn't (or won't be) guaranteed by the standard.

Quote:
>> Or is this a "too many people assumed sizeof(int) == sizeof(long) so it
>> can't change now" sorf of thing?

>    The only "rule" is that each type is "at least as big" as what comes
>before it.

Again that's one thing that isn't guaranteed (in the sizeof sense above),
although it is very likely to be true.

What is guaranteed is that short can represent all of the values that
signed char can represent, and so on. So if I define (a >>> b) to mean that
a can represent all of the values that b can represent (and possibly more)
then

     short     >>> signed char
     int       >>> short
     long      >>> int
     long long >>> long      (for C9X)

Note thgat plain char can be signed or unsigned so short >>> char is *not*
guaranteed.

Similarly

     unsigned short     >>> unsigned char
     unsigned int       >>> unsigned short
     unsigned long      >>> unsigned int
     unsigned long long >>> unsigned long      (for C9X)

In addition the range of an unsigned type is at least as large as the
positive range of the corresponding signed type so, for example
UINT_MAX >= INT_MAX

Each type has a minimum range of values that it must be able to represent

     signed char      -127 to 127
     short            -32767 to 32767
     int              -32767 to 32767
     long             -2147483647 to 2147483647

     unsigned char    0 to 255
     unsigned short   0 to 65535
     unsigned int     0 to 65535
     unsigned long    0 to 4294967295

Plain char must have a range that is the same as that of either signed char
or unsigned char. long long types will probably have some huge minimum
ranges. :-)

Quote:
>    int is at least as big as char
>    long is at least as big as int
>    long long is at least as big as long
>    so on, and so forth...

In terms of sizes all you know is that sizeof(char) is 1 and nothing else
can be smaller than that. It is likely that types wil larger ranges will
occuply larger objects but it isn't guaranteed (the standard permits
unused bits in representations). However the minimum ranges imply that
char types are at least 8 bits wide, short and int types are at least 16
bits wide, long types are at least 32 bits wide. long long will probably
be at least 64 bits wide.

Quote:
>    As long as the hardware maintains this relationship, they're free to
>do whatever they want.

Within the limits above.

--
-----------------------------------------


-----------------------------------------



Sun, 04 Feb 2001 03:00:00 GMT  
 long long vs. long?

...

Quote:
>Which is really annoying because with 64 bit machines we will end up with (
>okay not every one, but a lot of us will )

>char   8 bits
>short 16 bits
>long  32 bits
>long long 64 bits

>now if a long is at least as long as an int, that implies an int is no greater
>than a long, but an int is also supposed to be the 'natural' word size of the
>machine, which in this case would be 64 bits.

It depends. If the archetecture can support 32 bit operations just as
efficiently as 64 bit operations then it is quite reasonable to make int
32 bits wide (there may even be cache benefits etc. in doing so). For
example 68000 processors support operations in 16 bit and 32 bit operands
so int can be made 16 or 32 bits on those processors (16 bits was appropriate
on the earlier ones because on those 32 bit operations took more clock
cycles). OTOH I understand that some Cray implementations made all integer
type except char types 64 bits.

--
-----------------------------------------


-----------------------------------------



Mon, 05 Feb 2001 03:00:00 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. char size (was long long long long long int)

2. long long long long integers

3. short/long/long long Formatting questions

4. Long long and long double

5. long vs unsigned long

6. UINT, LONG vs. unsigned, long

7. long long vs. __int64

8. REPOST: Re: Neo Longest ThrREPOST: Re: Neo Longest ThrREPOST: Re: Neo Longest ThrREPOST: Re: Neo Longest Thread Ever II

9. REPOST: Re: Neo Longest ThrREPOST: Re: Neo Longest ThrREPOST: Re: Neo Longest ThrREPOST: Re: Neo Longest Thread Ever II

10. Long long :)

11. Availability of long long?

12. long long support VC/VC++ .NET?

 

 
Powered by phpBB® Forum Software