very long int

[davar55]

I noted recently in the forum someone referred to
the integer type "long long". Does this refer to
an integer type with 64 bits? Or perhaps 128?
I doubt that my c5.5.1 compiler supports it, and my
test trial failed to get past the declaration.

I once thought the adverbal phrase "very long" would be
used to get a 64 bit type, and "very very long" 128.
Same basic idea. I'd love to get a 64 bit integer from
my compiler, to match the w8 x64 hw.

[science_man_88]

Originally Posted by davar55

I noted recently in the forum someone referred to
the integer type "long long". Does this refer to
an integer type with 64 bits? Or perhaps 128?
I doubt that my c5.5.1 compiler supports it, and my
test trial failed to get past the declaration.

I once thought the adverbal phrase "very long" would be
used to get a 64 bit type, and "very very long" 128.
Same basic idea. I'd love to get a 64 bit integer from
my compiler, to match the w8 x64 hw.

http://en.wikipedia.org/wiki/Integer...ral_data_types shows it to be 64 bits

[Dubslow]

Originally Posted by science_man_88

http://en.wikipedia.org/wiki/Integer...ral_data_types shows it to be 64 bits

Dear lord that is wrong -- the meaning of "long" varies from language to language, and in C their size is "implementation defined". So for me on GNU-Linux, an int is 32 bits while a long is 64, however on Windows (at least Visual Studio) an int and long are both 32 bits. Davar will simply have to experiment (or otherwise research) what size a long long is for him.

#include <stdio.h>

int main(void) {
  printf("a long long has %d bytes\n", sizeof(long long int));
  return 0;
}

[davar55]

Thanks. I can't compile that code, it gives the "error"
"Too many types in declaration."
The Borland c5.5.1 is an older compiler and I'm not sure
whether it can generate 64 bit object code
Perhaps using an argument flag I haven't tried yet.

I earlier tried:

long long x;
 
void main(void)
{
}

and the compiler errs on the first line, same error.

[Xyzzy]

#include <stdio.h>
#include <limits.h>

int main() {
  printf("Size of Char %d\n", CHAR_BIT);
  printf("Size of Char Max %d\n", CHAR_MAX);
  printf("Size of Char Min %d\n", CHAR_MIN);
  printf("Size of int min %d\n", INT_MIN);
  printf("Size of int max %d\n", INT_MAX);
  printf("Size of long min %ld\n", LONG_MIN);
  printf("Size of long max %ld\n", LONG_MAX);
  printf("Size of short min %d\n", SHRT_MIN);
  printf("Size of short max %d\n", SHRT_MAX);
  printf("Size of unsigned char %u\n", UCHAR_MAX);
  printf("Size of unsigned long %lu\n", ULONG_MAX);
  printf("Size of unsigned int %u\n", UINT_MAX);
  printf("Size of unsigned short %u\n", USHRT_MAX);
  return 0;
}

[Dubslow]

According to Wikipedia, long long is new to C99. It must be an incredibly old compiler, or there might be an option to compile to C99 standards instead of the original ANSI C.

[ewmayer]

When I was first learning C I found the lack of unambiguous data typing (analogous to Fortran-style 'integer*4') to be an appalling piece of stupidity. Since we are still stuck with it, I can only surmise that the folks that populate the C-related standards boards secretly enjoy such arcana.

Solution now is just as then: put together a header file containing the needed typedefs for the various platforms of interest to you, such that your code using said typedefs only shows the resulting unambiguous type, e.g. uint64. Write a small "on program start" test utility which checks the lengths and any other key type attributes (e.g. floating point ranges) at runtime.

[Dubslow]

I read that the ill defined sizes were so that if you, say, wanted to write a C compiler on some something with like a few kilobytes of memory total, you (the implementation creator) could implement the types to be smaller than usual, right at the lower limit of the possible size range so that you would have to rewrite existing code (i.e. change to smaller types) as little as possible (any code that runs on such a device probably wouldn't rely on an int being 32 bits, since that's an unusual requirement [this forum being an exception]).

tl;dr extreme portability.

[chalsall]

Originally Posted by ewmayer

When I was first learning C I found the lack of unambiguous data typing (analogous to Fortran-style 'integer*4') to be an appalling piece of stupidity. Since we are still stuck with it, I can only surmise that the folks that populate the C-related standards boards secretly enjoy such arcana.

As has been said many times before, both here and elsewhere...

"C -- All the power, and all the safety features, of a chain saw...."

[ewmayer]

Originally Posted by Dubslow

I read that the ill defined sizes were so that if you, say, wanted to write a C compiler on some something with like a few kilobytes of memory total, you (the implementation creator) could implement the types to be smaller than usual, right at the lower limit of the possible size range so that you would have to rewrite existing code (i.e. change to smaller types) as little as possible (any code that runs on such a device probably wouldn't rely on an int being 32 bits, since that's an unusual requirement [this forum being an exception]).

Which was of very great importance ... 30-40 years ago. Fortran-90 solved this in a more modern fashion via typedef foo_t = "get type of at least this size and precision" functionality.

tl;dr extreme portability.

I don't consider having to write custom header files and then deal with the inevitable bugs/crashes resulting from the inevitable hidden size assumptions which creep into one's code as an example of "portability". Allowing me to specify 'integer*4' and be guaranteed that I get just that (or at least that), in a highly visible type-size-encoding fashion ... that's portable.

I stand by my "appalling piece of stupidity" categorization. And it even stupider now than it was then.

[Dubslow]

I agree it's quite dumb for a modern language. I was just trying to lend some perspective. (Keep in mind these choices were made in the 80s, and have been kept for backwards compatibility.)