Re: integer to string conversion

Felix von Leitner ([email protected]) wrote:
> Thus spake Richard Wossal ([email protected]):
>
>    
>> I was going to ask you about your opinion whether or not
>> the non-standard itoa-family of functions have a place in
>> dietlibc, when I discovered that the dietlibc features
>> __ltostr (and derivates). I've never seen that before,
>> Internet says they come from HP-UX.
>>      
> Uh, we invented that interface ourselves. It's not for public
> consumption.  The official way to do it is to use sprintf, which sucks,
> obviously.
>
> So my recommendation is to use fmt_* from libowfat
> (www.fefe.de/libowfat/)
>
>    
>> Now what I would like is a function family in the
>> dietlibc that looks like the following:
>>          int itoa(int n, char *buf, int base)
>> returning the length of n in characters.
>>      
>    
>> Do you think, a libc is the right place for those?
>> After all, they are not "less standard" than the
>> __ltostr functions, are they?
>> And (on a side note), why doesn't embutils use
>> __ltostr?
>>      
> __ltostr is not portable at all, it's only an internal function used by
> sprintf in dietlibc.  Do not use it, even if you checked for it's
> existance!
>
> As a rule of thumb: if the function name starts with __, stay away from
> it :-)
>
> A function like that does not belong in libc, because there is a
> standard that says what libc should export.  Actually, there is more
> than one.  But it's standardized.  What good is standardization if you
> ignore it and add stuff?
>
> Felix
>
>    

Actually, that answers two questions I carried around subconsciously:
"Why would I want libowfat, when I got dietlibc?" (admittedly, I never
even looked at it) and
"Why the hell am I supposed to type underscores in front of some
randomly choosen subset of functions?"

Well, that's what they call "growing up" I guess... :)

Thanks a lot!

Richard