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 28 13:52, Christian Franke wrote:
>> Corinna Vinschen wrote:
>>>>>>> [...]
>>>>>> Does anybody actually *need* itoa/utoa as long as we have __itoa/__utoa?
>>>>> [...]
>>> 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.
> I never doubted that.  My question is NOT how we can keep itoa/utoa
> alive and striving.  I think we have really only two ways of going
> forward:
>
>    #if __CYGWIN__'ize itoa/utoa prototypes in stdlib.h, but DO NOT
>    #if __CYGWIN__'ize __itoa/__utoa, because they are living in
>    reserved namespace anyway

The DO NOT branch would only make real sense if Cygwin would provide the 
__*() functions, As this is not the case, my patch disables also these 
prototypes.
...


> or
>
>    drop the definitions of itoa/utoa from itoa.c and utoa.c, drop the
>    prototypes from stdlib.h, but NEITHER drop __itoa/__utoa from
>    the source files NOR drop their prototypes.
>
> I favor the second approach, but if we can't get this sorted out
> within the next two days, we'll go ahead with the first approach.
>
>
> Corinna
>