Keith Thompson wrote:
Mark Shelor <ms*****@comcast.removeme.net> writes:
Problem: find a portable way to determine whether a compiler supports
the "long long" type of C99.
As others have pointed out, the relevant macros are LLONG_MAX and
ULLONG_MAX. But since "long long" appeared as an extension before it
was blessed by the C99 standard, there may be implementations that
provide long long but don't have LLONG_MAX and ULLONG_MAX.
BTW, are you really looking for type long long or for a 64-bit type?
Type long long is guaranteed to be at least 64 bits, but there could
be implementations that don't define long long, but that have 64-bit
longs. Consider using uint64_t or uint_least64_t from <stdint.h> If
your implementation doesn't have <stdint.h>, Doug Gwyn has written a
reasonably portable C90-compatible implementation of it; see
<http://www.lysator.liu.se/c/q8/index.html>.
Thanks Keith, Arthur, Chris for the helpful replies.
Yes, I did try using ULLONG_MAX earlier in the day, but had no luck
there either. Oddly, when I grep'd on ULONG_LONG_MAX in the
/usr/include subdirectories, the response I got was
$ grep ULONG_LONG_MAX `find /usr/include -print`
/usr/include/limits.h:# define ULLONG_MAX ULONG_LONG_MAX
However, since this #define was nested within other #ifdef's that
apparently get excluded during the compile, the token ULLONG_MAX didn't
show up as being defined.
If I remove my original conditional compilation directive, and simply go
ahead and include the 64-bit code (with unsigned long long's),
everything compiles and runs just fine. So, this has me scratching my
head a bit.
I'm using this #ifdef in a package I wrote for CPAN. It's a C
implementation (wrapped in a Perl module) of NIST's Secure Hash
Algorithms (SHA-1/256/384/512). Basically, the latter two (384/512) use
64-bit operations, so I note in my documentation that run-time code for
them won't exist if one's native compiler lacks support for long long's.
However, the package will still compile and run just fine.
Since this package gets downloaded, compiled, and installed by lots of
people with C compilers of unknown capability, I've written the code to
be as vanilla and portable as possible. What I DON'T want to have
happen is for a person's compile to crash if his compiler doesn't happen
to support long long's. It's acceptable in those circumstances for the
package to omit support for SHA-384 and SHA-512, which fortunately
aren't really crucial in the near-term anyway.
Yet another oddity is the fact that the 64-bit code gets included when I
compile it under the automake facility that's provided as part of the
Perl packaging utility (h2xs). However, when I compile it as a
standalone C program with a simple test driver, the 64-bit code is
missing. I don't have the patience to wade through the myriad compiler
options and define's used by h2xs to figure out what's going on! :)
Regards, Mark