[PATCH] unify itoa

Rob Landley rob at landley.net
Mon Jul 10 07:43:56 UTC 2006


On Sunday 09 July 2006 12:53 pm, 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...

How many of these users actually need a malloc, and how many is it essentially 
a better sprintf?

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

A) Not on Linux.  Linux standardized on LP64.

B) If it's that broken, I don't care.

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

I'd rather wait until users of long long show up before adding support.  
Also, "long long" isn't a specific type: on a 32 bit platform long is 32 bits 
and long long is 64 bits.  On a 64 bit platform, long is 64 bits and long 
long is 128 bits.  That's why they invented uint64_t and friends. :)

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

Well, it's definitely an improvement.  However, it would be nice if you could 
call itoa on a buffer and have it actually fill in that buffer from the 
start, so you could use it like you could sprintf or strcpy, and not 
potentially have to track two pointers to your own buffer.

I did a quick stab at that and checked it into xfuncs.c, and now I'm about to 
pass out.  Could you tell me if that's useful, or if not what did I screw up?  
I have to go fall over and pass out now, it's 4 am and I have work in the 
morning...

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list