macOS Longest integer type in OS X

[Eddiestein]

What is the longest integer type available in OS X 10.5 (on a Core 2 Duo machine - it's 64-bit)? The longest I could find was 276447232 which will not work for what I want to do. I'll need at least 100000000000000 (that's 15 digits).

Usually a signed long long would be at least 9223372036854775807 but OS X seems to treat it as a long, where the limit is 276447232.

Eddie

 

[Eddiestein]

Ahh, just had to compile it in 64-bit mode.

gcc -o theprogram theprogram.c -arch x86_64

 

[Krevnik]

Even in 32-bit, a long long should be 64-bits in size. Macros which tell you the max int size will likely give you the max for the native width integer.

When printing a 64-bit int on 32-bit systems to a console, you will need a different escape code in the format string though, so that might be why a long long doesn't appear to have the right max size in a 32-bit process.

 

[sord]

And if you need to go higher, look into using GMP (the GNU MP Bignum library). There is a Mac OS X Framework for it too if you are doing a Cocoa application.

 

[pld]

I know this thread is a bit old, but I have just been tasked with porting an existing Win32/Solaris/Linux application to MacOS and have run up against this same issue. It appears that 'long long' is only sized to 4 bytes, not 8 bytes, unless the '-arch x86_64' switch is used, as posted by Eddiestein.

But that begs the question: Is this a 64-bit system? Are ALL MacIntel machines (as in, every single one that has ever been shipped) a 64-bit system?

 

[Krevnik]

The first generation of Mac Intel machines were 32-bit, as they used the Core Duo. Intel didn't go fully 64-bit with their hardware until the Core 2.

 

[lee1210]

But that begs the question: Is this a 64-bit system? Are ALL MacIntel machines (as in, every single one that has ever been shipped) a 64-bit system?

No. Core Solo and Core Duo are 32-bit. I won't try to enumerate the machines with these chips, but there are quite a few of them.

-Lee

 

[gnasher729]

I know this thread is a bit old, but I have just been tasked with porting an existing Win32/Solaris/Linux application to MacOS and have run up against this same issue. It appears that 'long long' is only sized to 4 bytes, not 8 bytes, unless the '-arch x86_64' switch is used, as posted by Eddiestein.

That would be very strange. "long long" is a Standard C data type, it is required to be at least 64 bit in size, and it is supported by all gcc compilers, whether for PowerPC 32 or 64 bit, Intel 32 or 64 bit, or ARM.

So what exactly makes you think that "long long" is 4 bytes in size?

But that begs the question: Is this a 64-bit system? Are ALL MacIntel machines (as in, every single one that has ever been shipped) a 64-bit system?

That is completely irrelevant. long long is at least 64 bit, whether your computer is an 8 bit, 16 bit, 32 bit or 64 bit computer.

 

[dannomac]

That is completely irrelevant. long long is at least 64 bit, whether your computer is an 8 bit, 16 bit, 32 bit or 64 bit computer.

That's correct. Here's evidence:

dan@meshach:~/t% uname -srm
Darwin 9.6.0 Power Macintosh
dan@meshach:~/t% cat test.c
#include <stdio.h>

int main(int argc, char **argv) {
   printf("long long is %i bytes\n", sizeof(long long));
   return 0;
}
dan@meshach:~/t% make test
cc     test.c   -o test
dan@meshach:~/t% ./test
long long is 8 bytes
dan@meshach:~/t%

More evidence:

dan@shadrach:~/t% uname -srm
FreeBSD 7.1-RELEASE-p2 amd64
dan@shadrach:~/t% cat test.c
#include <stdio.h>

int main(int argc, char **argv) {
   printf("long long is %i bytes\n", sizeof(long long));
   return 0;
}
dan@shadrach:~/t% make test
cc -O2 test.c  -o test
dan@shadrach:~/t% ./test
long long is 8 bytes
dan@shadrach:~/t%

 

[dannomac]

Further, all C99 compliant compilers such as newer GCCs define a header file called inttypes.h, which defines several integer types:

uint8_t
int8_t
uint16_t
int16_t
uint32_t
int32_t
uint64_t
int64_t

Too bad that even Visual C++ 2008 doesn't support this.

 

[gnasher729]

Further, all C99 compliant compilers such as newer GCCs define a header file called inttypes.h, which defines several integer types:

uint8_t
int8_t
uint16_t
int16_t
uint32_t
int32_t
uint64_t
int64_t

Too bad that even Visual C++ 2008 doesn't support this.

But Visual C++ supports DWORD

 

[pld]

I tried the test code from dannomac and the size of 'long long' does indeed appear to be 8 bytes. gnasher729 asked the question, "So what exactly makes you think that "long long" is 4 bytes in size?" A very good question indeed. So here is a modified version of dannomac's test program:

#include <stdio.h>

#define VOID_UINT64 0xFFFFFFFFFFFFFFFF // max unsigned 64 bits
#define VOID_INT64 -9223372036854775807 // max neg signed 64 bits

int main(int argc, char **argv) {
unsigned long long ubig_var;
long long big_var;

printf("long long is %i bytes\n", sizeof(long long));
printf("big_var is %i bytes\n", sizeof(big_var));
printf("ubig_var is %i bytes\n", sizeof(ubig_var));

big_var = VOID_INT64;
ubig_var = VOID_UINT64;

printf("ubig_var = %llX\n", ubig_var);
printf("big_var = %lli\n", big_var);
return 0;
}


... and the results I get:


> gcc test.c -o test
test.c: In function 'main':
test.c:14: warning: integer constant is too large for 'long' type
test.c:15: warning: integer constant is too large for 'long' type
> test
long long is 8 bytes
big_var is 8 bytes
ubig_var is 8 bytes
ubig_var = FFFFFFFFFFFFFFFF
big_var = -9223372036854775807
>


The two warnings are for the lines where the 'long long' variables are assigned 'long long' values, but as you can see, the assignments work fine. So ... the compiler warnings are completely bogus.

FYI:
> uname -srm
Darwin 9.2.1 i386
> gcc --version
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490)

 

[gnasher729]

So here is a modified version of dannomac's test program:

#include <stdio.h>

#define VOID_UINT64 0xFFFFFFFFFFFFFFFF // max unsigned 64 bits
#define VOID_INT64 -9223372036854775807 // max neg signed 64 bits

int main(int argc, char **argv) {
unsigned long long ubig_var;
long long big_var;

printf("long long is %i bytes\n", sizeof(long long));
printf("big_var is %i bytes\n", sizeof(big_var));
printf("ubig_var is %i bytes\n", sizeof(ubig_var));

big_var = VOID_INT64;
ubig_var = VOID_UINT64;

printf("ubig_var = %llX\n", ubig_var);
printf("big_var = %lli\n", big_var);
return 0;
}


test.c:14: warning: integer constant is too large for 'long' type
test.c:15: warning: integer constant is too large for 'long' type


The two warnings are for the lines where the 'long long' variables are assigned 'long long' values, but as you can see, the assignments work fine. So ... the compiler warnings are completely bogus.

Unless you use the right compiler options, the gcc compiler will compile C90 with gcc extensions, and not C99. "long long" and "unsigned long long" are not part of the C90 language; they were added in C99. The large constants cannot be represented in the longest C90 type, which is "long". Exactly what the warning says: "integer constant is too large for 'long' type"

 

[iSee]

...
The two warnings are for the lines where the 'long long' variables are assigned 'long long' values, but as you can see, the assignments work fine. So ... the compiler warnings are completely bogus.

FYI:
> uname -srm
Darwin 9.2.1 i386
> gcc --version
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490)

I *think* you need to specify (long long) and (unsigned long long) literals with ll (el el) or ull (u el el) following the number. That is, your #defines should be:

#define VOID_UINT64 0xFFFFFFFFFFFFFFFFull // max unsigned 64 bits
#define VOID_INT64 -9223372036854775807ll // max neg signed 64 bits

I think its only complaining about this in lines 14 and 15 rather than above because the #define lines are processed by the preprocessor, not the compiler. It's not till they are used that the compiler gets involved and processes the literals.

DISCLAIMER + apology: Sorry, I don't recall this for sure and I don't have time to look it up right now, so I'm sorry if I send you down the wrong path. I might still be worth a try.

 

[pld]

Either of the posted solutions (using -std=c99 compiler switch, adding explicit sizes to the typedefs) eliminates the warnings.

Neither of the solutions has any obvious effect on the actual behavior of the test program.

So I have added the explicit sizes to the typedefs (modified 3 files) and am proceeding on with port my project. Once I get everything to compile (see thread for linker problems), I will do extensive testing to see if I need to use the c99 switch (requiring platform-specific modifications to 20+ make files).

Thanks for the responses. This is the first time I have used an on-line forum where people actually responded, much less helped me solve a problem.