trafficserver-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Plevyak <>
Subject Re: stdint.h
Date Wed, 19 May 2010 04:35:26 GMT

There are standard macros for doing that (e.g. PRIu64) which are defined
in /usr/include/inttypes.h for ISO C99 7.8.

If we had to go that route I would go with those rather than a
roll-your-own even if that means defining them on platforms that
don't have ISC C99 support yet (only a decade past).

However, since the C99 and new C++ standard declares that long long int
is 64-bit and since just about everyone already has that:
linux, solaris, freebsd, mac, and since I have been able to use it
portably for several years now I would rather go that route.

If there is a platform which doesn't support long long int as 64-bit
I don't doubt that it supports 64-bit at all and I doubt we will
every be called upon to support it, and given that it is the new
standard, if we ignore the problem it will, very definitely, go away.


On 5/18/2010 9:15 PM, Mladen Turk wrote:
> On 05/19/2010 02:52 AM, John Plevyak wrote:
>> Why the hell uint64_t is defined this way and g++ complains even
>> though long int == long long it is beyond me.
>> Suggestions, comments?
> I saw whole bunch of %ld, %lld stuff in the code which will IMHO
> never be portable no matter what type you use.
> With APR (and some other projects) we detect those types
> at configure time, and define printf/scanf macros
> eg. apr_int64_t, apr_uint64_t and then have
> This makes printf/scanf code a little bit longer:
> eg. printf("Use some %" APR_UINT64_FMT_T " 64-bit integer\n",
> (apr_uint64_t)foo);
> but it is portable, especially between 32 and 64 bit compilers
> Think we should use something like that, because we already
> have the detection code (from other projects) and it works well
> for a variety of different compilers.
> At the end it's more or less discipline and search/replace,
> and I was going to add them anyhow.
> Regards

View raw message