[pdf-devel] Re: need better testing for int64_t

[Scott Fohey]

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 <address@hidden> 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