Perhaps the attached patch is the "right way" to identify int64_t presence?
Can someone who has access to a platform without int64_t try it out? (I've added a case to configure.ac to test for int64_t, and #defined HAVE_INT64_T if autoconf finds that it exists) --Scott On Wed, Dec 2, 2009 at 10:48 PM, Scott Fohey <[email protected]> wrote: > in pdf-types.h is the following: > > #if defined(int64_t) && !defined(PDF_FORCE_BIGNUMS) > #define PDF_USE_BUILTIN_64BIT_SUPPORT > #endif > > The problem is that int64_t is not #defined on my system (although there > is a typedef for it!), so I end up with the emulated 64-bit math. > > My system is ubuntu on a 64-bit AMD processor - if that makes any difference. > > My system stdint.h file does this: > > # if __WORDSIZE == 64 > typedef long int int64_t; > # else > __extension__ > typedef long long int int64_t; > # endif > > so I get the typedef, but no #define int64_t. I suspect that the presence of > <stdint.h> in the system is inhibiting the generation of this file > from /lib/stdint.in.h > wherein if int64_t is typedefd it is also #defined, > > Would it be safe to replace the test for defined(int64_t) with a check of > (__WORDSIZE == 64), or of (LONG_MAX >> 31 >>31 == 1)? > > I cannot seem to find any good mechanism to test for the presence of > int64_t... > Seems to me like something autoconf ought to be providing, right? All > I can find > in config.h is HAVE_LONG_LONG_INT, which isn't exactly right either. > > Anybody know the "right way" to correct this? > > --Scott >
int64_Merge_Directive
Description: Binary data
