[PATCH] unify itoa

[Rich Felker]

On Sun, Jul 09, 2006 at 06:53:25PM +0200, Denis Vlasenko wrote:
> On Sunday 09 July 2006 17:47, Rob Landley wrote:
> > > I think that some programs may print so much numerical output
> > > that it may be important for them to do itoa more-or-less
> > > efficiently.
> > 
> > Could you give me an example?  (Your patch didn't actually convert many users, 
> > that I saw.)
> 
> Examples of things which should care about it
> (I do not claim that current code cares):
> od, seq, uniq -c, tcpdump, hexdump...

Of these od/hexdump are the only ones that sound very interesting to
optimize for performance, and the 'itoa' code in question is
decimal-only anyway making them irrelevant.

Anyway if snprintf is too slow then what needs to be fixed is
snprintf, not the applications that use it. The C library exists for a
reason. As soon as you decide you can't rely on it to do what it's
supposed to do and do it at an acceptable level of efficiency, you end
up with the bloat that is Mozilla (NSPR), GNOME (glib), or coreutils
(gnulib, i.e. half of glibc copied into the coreutils source tree...).

> > > gcc optimizes it out to simple 1000000000 constant
> > > (if sizeof(unsigned)==4, that is).
> > 
> > When is sizeof(unsigned) not going to be 4 on any Linux platform?  We use the 
> > lp64 model (as do all modern Unix variants, including MacOS X), where only 
> > long and pointer are 64 bit.
> > 
> > http://www.unix.org/whitepapers/64bit.html
> 
> What about Alpha? I heard that it has (had?) sizeof(int)==8.

gcc does not support sizeof(int)!=4, so no, it does not have 8. You're
thinking of long. In fact any C compiler with sizeof(int)!=4 is
virtually unusable for multimedia apps because it means you lack at
least one of the sizes 8, 16, or 32, all of which are needed in order
to have any hope of efficient audio and video processing.

Rich