Longest integer type in OS X

Discussion in 'Mac Programming' started by Eddiestein, Dec 23, 2007.

  1. Eddiestein macrumors member

    Joined:
    Jul 30, 2007
    #1
    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
     
  2. Eddiestein thread starter macrumors member

    Joined:
    Jul 30, 2007
    #2
    Ahh, just had to compile it in 64-bit mode.

    Code:
    gcc -o theprogram theprogram.c -arch x86_64
     
  3. Krevnik macrumors 68040

    Krevnik

    Joined:
    Sep 8, 2003
    #3
    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.
     
  4. sord macrumors 6502

    Joined:
    Jun 16, 2004
    #4
    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.
     
  5. pld macrumors newbie

    Joined:
    Feb 11, 2009
    #5
    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?
     
  6. Krevnik macrumors 68040

    Krevnik

    Joined:
    Sep 8, 2003
    #6
    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.
     
  7. lee1210 macrumors 68040

    lee1210

    Joined:
    Jan 10, 2005
    Location:
    Dallas, TX
    #7
    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
     
  8. gnasher729 macrumors P6

    gnasher729

    Joined:
    Nov 25, 2005
    #8
    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?

    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.
     
  9. dannomac macrumors member

    Joined:
    Mar 11, 2008
    Location:
    Saskatoon, SK
    #9
    That's correct. Here's evidence:

    Code:
    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:
    Code:
    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% 
    
    
     
  10. dannomac macrumors member

    Joined:
    Mar 11, 2008
    Location:
    Saskatoon, SK
    #10
    Further, all C99 compliant compilers such as newer GCCs define a header file called inttypes.h, which defines several integer types:
    Code:
    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.
     
  11. gnasher729 macrumors P6

    gnasher729

    Joined:
    Nov 25, 2005
    #11
    But Visual C++ supports DWORD :D
     
  12. pld macrumors newbie

    Joined:
    Feb 11, 2009
    #12
    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)
     
  13. gnasher729 macrumors P6

    gnasher729

    Joined:
    Nov 25, 2005
    #13
    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"
     
  14. iSee macrumors 68040

    iSee

    Joined:
    Oct 25, 2004
    #14
    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.
     
  15. pld macrumors newbie

    Joined:
    Feb 11, 2009
    #15
    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.
     

Share This Page