I hate to say it, but the simplest thing is to use long long int for all this junk. In practice that is what it is on most systems, or at least that covers their useful range.
The unfortunate answer is that C/C++ is just plain ill considered. The argument that you should just use cout is ludicrous as a typical cout implementation has 17 hidden mallocs just to output a simple line with a variable in it (see the fastformat site). Given that traffic server has (or at least had) exactly zero mallocs on the critical path and nevertheless the freelist allocator is the top profiled function make it abundantly clear that cout is not a rational answer for high performance systems. So that leaves us with the lowest common demoninator which is the standard 64-bit number which is long long int (a stupid name if there ever was one). As they say about political systems, C/C++ is the worst language... except for all the others. john On 5/18/2010 10:23 PM, Mladen Turk wrote: > On 05/19/2010 07:02 AM, John Plevyak wrote: >> >> I would say that if we can't find a system which doesn't >> support the standard %lld for 64-bit numbers then we should >> just go with the standard. It is simpler and it will only >> be more right as time passes because it is the standard. >> > > Fair enough. Makes sense since we are not supporting > such waste majority of platforms and compilers like APR. > > However how about const numeric macros > (123UL and 123ULL for example) > Are they safe enough for using them both with uint64_t and inku64? > > And I suppose we'll have to cast the ink_off_t to ink64 > all the times. > There's also a pid_t format error problem, but I > suppose we don't use that so widely. > > What about ssize_t and size_t? This can be either > %d, %ld and %u or %lu AFAICT > > > Regards
