Wireshark · Ethereal-dev: Re: [Ethereal-dev] Fun PRI[doxu]64 problem on AIX 4.3.2 for 0.10.5

[Guy Harris <gharris@xxxxxxxxx>]

On Mon, Jul 12, 2004 at 11:50:23PM -0500, Albert Chin wrote:
> For AIX 4.3.2 (not 4.3.3 or 5.x), <sys/inttypes.h> has:
>   #define PRId8           %hd
>   #define PRId16          %hd
>   #define PRId32          %d
>   #if defined(__64BIT__)
>   #define PRId64          %ld
>   #else
>   #if defined(_LONG_LONG)
>   #define PRId64          %lld
>   #endif

I guess either

	1) IBM were still experimenting with that stuff and hadn't yet
	   figured it it was the wrong way to go (OK, kids, how do you
	   write "%.3d" using the PRId{8,16,32,64} macros?)

or

	2) the C99 committee (that's a C99ism, right?) were still
	   experimenting and hadn't yet figured out it was the wrong way
	   to go.

> As the test fails, ethereal defines PRId64. But, because the IBM C
> compiler does not like re#defining a macro,

Presumably it doesn't mind #undef-ing the macro and re-#defining it.

> What is the best way to fix this?

If it's possible, the best way is probably to convince autoconf to add a
#undef of PRI[doux]64 before the #defines - the AIX 4.3.2 ones are
sufficiently bogus that I'd be inclined to classify it as being an OS
without sensible definitions, even though it happens to define them, so
we're better off defining them ourselves.

Note, BTW, that this is also an issue for top-of-tree tcpdump CVS, as it
also assumes native 64-bit integer support and relies on the PRI[doux]64
macros.