[PATCH] unify itoa

[Denis Vlasenko]

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...

> > 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.

BTW, I could do this instead:

static inline unsigned max_unsigned_power10(void)
{
        if (sizeof(unsigned) == 4) return 1000000000;
        if (sizeof(unsigned) == 8) // gcc warns a lot here, shut it up
                return (unsigned)(10ULL*1000000000*1000000000);
        return BUG_unsupported_architecture();
}

but since you don't want to handle long long, it's irrelevant for now.

> > So, do you want me to
> >
> > a) remove #ifdef NOT_NEEDED_YET part
> > 	or
> > b) enable it and use it in ash?
> 
> The first, please.
> 
> A general rule of thumb: we can always add code to the tree later.  (And if we 
> remove it, we can always add it _back_ later.)

See attached patch.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox_itoa_v3.patch
Type: text/x-diff
Size: 5808 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20060709/00d19121/attachment.bin