Re: Hide non-standard itoa/utoa() in stdlib.h or drop these functions?

[Christian Franke <Christian.Franke@t-online.de>]

Corinna Vinschen wrote:
> On Jan 24 10:42, Christian Franke wrote:
>> brian.inglis@systematicsw.ab.ca wrote:
>>> On 2024-01-23 02:03, Corinna Vinschen wrote:
>>>> On Jan 22 19:46, Christian Franke wrote:
>>>>> The functions itoa() and utoa() are non-standard, not exported
>>>>> by Cygwin and
>>>>> also unavailable on FreeBSD and Linux (glibc and musl libc).
>>>>> Busybox for
>>>>> example could not be build OOTB using newlib's stdlib.h because
>>>>> there are
>>>>> conflicts with local functions with same names but different
>>>>> signatures.
>>>>> [...]
>>>> Does anybody actually *need* itoa/utoa as long as we have __itoa/__utoa?
>>> Unix 1st ed Manual defined itoa as did K&R on p60 (/p64 2ed); at least
>>> IBM and QNX and "some compilers" provide itoa and others:
>>>
>>>      https://cplusplus.com/reference/cstdlib/itoa/
>>>
>>> other libraries also provide {,u}{,l}ltoa.
>> This page suggests that at least the K&R version was different (no radix
>> parameter):
>> https://en.wikibooks.org/wiki/C_Programming/stdlib.h/itoa
> Also, the fact that it has been mentioned in K&R was apparently no
> incentive to standarize it later on.  That's why its existence on
> various systems is a bit erratic.
>
>>> Newlib provided the function and man pages, which should be updated to
>>> reflect the changed situation, as they will have been used, and users
>>> will want to know what happened and what to do e.g. use prefixed
>>> functions, #define, sprintf(3), etc.
> Mind, I never said to remove the underscored functins.  So the
> functionality still exists, it's just called __foo instead of foo.
>
>>> Downstream systems should note the change in their lists of supported
>>> functions, and in their release notes.
> We don't have any influence on downstream, but if downstream wants the
> API, it's easy to provide it by aliasing foo to __foo in a downstream
> header.
>
>> Newlib should IMO at least provide an easy way to hide the [iu]toa()
>> prototypes without hiding other BSD or GNU extensions. The prototypes should
>> not be visible if for example _GNU_SOURCE is defined and no other _*_SOURCE.
>> This is currently not possible. Such a change would possibly require only
>> minor documentation updates.
> The problem is that _GNU_SOURCE got synonymous for "everything and the
> kitchen sink", and there's no blessed way around that other than
> defining another source standard instead.

My interpretation was "everything and the kitchen sink - except 
everything never provided by glibc or Linux" :-)


> Do we really want to create our own kind of "this is
> non-standard"-standard?
>
> That would be something like __NEWLIB_VISIBLE / _NEWLIB_SOURCE.
>
> But, then again, for just two seldom used APIs?

The API is seldom used, possibly not or no longer well known and 
definitely unavailable in widely used other C libs. This increases the 
risk of a conflict with local functions with the same name. Busybox is a 
real world example.

If it will be decided to keep this API as is, please consider to accept 
my patch from the start of this thread. It IMO obviously makes sense 
because Cygwin does not provide this API. This could at least simplify 
my patch for the busybox Cygwin package and may increase the probability 
that it will be accepted by busybox upstream.