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 06:25:46 GMT

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.


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

View raw message