long long vs long

[Benjamin Riefenstahl]

Hi Michael,


Michael H. Warfield wrote:
>         Unfortunately the standard also specifies the length of several
> types.  Specifically char is 8 bits, short is 16 bits, and long is 32 bits.

No, it only specifies the *minimum* ranges that each type must cover and
it gives some relations like all values representable by "short" must
also be representable by "int" and "long" etc. The net result for most
current architectures are the conditions (I hope I don't miss anything
important)

  sizeof(char) == 1  // that's a definition actually, not a condition
  sizeof(char) * CHAR_BITS >= 8
  sizeof(short) * CHAR_BITS >= 16
  sizeof(int) * CHAR_BITS >= 16
  sizeof(long) * CHAR_BITS >= 32
  sizeof(int) >= sizeof(short)
  sizeof(long) >= sizeof(int)

The language standard does not say that "int" must be similar to one of
"short" or "long", so an implementation that does

  sizeof(short) * CHAR_BITS == 16
  sizeof(int) * CHAR_BITS == 32
  sizeof(long) * CHAR_BITS == 64

is prefectly comforming.

The main argument for a new type "long long" as I understood it in the
Newsgroup discussions was that there was just too much code out there
that relies on binary compatibility for the "long" type. A compiler that
wants binary compatibility *and* a 64 bits type must introduce a new
type.

One argument against was that the current standard guarantees that
"long" is the type with the largest range of them all. This makes code
like this legal and portable:

  size_t size = sizeof(someobject);
  fprintf( somefile, "%lu", (unsigned long) size );

with the guarantee that the cast will not truncate the value. The new
type can change this code without warning, because with a new type
size_t might be an alias for "long long" instead of maximally "long".
This was probably considered a rather obscure point by some. But than I
sometimes feel like portability issue often are about rather obscure
points, which is probably why they get missed so often.

I can only recommend to search the comp.std.c newsgroup for the topic in
Dejanews.


so long, benny
======================================
Benjamin Riefenstahl (benny@crocodial.de)
Crocodial Communications EntwicklungsGmbH
Ruhrstraße 61, D-22761 Hamburg, Germany
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".