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

  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.

See the original posts on the Cygwin list for more details:
https://sourceware.org/pipermail/cygwin/2024-January/255216.html
https://sourceware.org/pipermail/cygwin/2024-January/255217.html

Corinna proposed to either drop these functions entirely or hide the 
prototypes on Cygwin only. I attached a patch for the second alternative.
  

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.
> 
> See the original posts on the Cygwin list for more details:
> https://sourceware.org/pipermail/cygwin/2024-January/255216.html
> https://sourceware.org/pipermail/cygwin/2024-January/255217.html
> 
> Corinna proposed to either drop these functions entirely or hide the
> prototypes on Cygwin only. I attached a patch for the second alternative.
> 
> -- 
> Regards,
> Christian
> 

> From 5f1c43796c6a125f04c1f2436fc1048783ce3b7a Mon Sep 17 00:00:00 2001
> From: Christian Franke <christian.franke@t-online.de>
> Date: Mon, 22 Jan 2024 19:11:20 +0100
> Subject: [PATCH] Hide itoa, utoa, __itoa and __utoa in stdlib.h on Cygwin only
> 
> These functions are non-standard and not exported by Cygwin.
> 
> Signed-off-by: Christian Franke <christian.franke@t-online.de>
> ---
>  newlib/libc/include/stdlib.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/newlib/libc/include/stdlib.h b/newlib/libc/include/stdlib.h
> index 15b349440..fd89f5ba7 100644
> --- a/newlib/libc/include/stdlib.h
> +++ b/newlib/libc/include/stdlib.h
> @@ -221,11 +221,13 @@ char *	ecvtbuf (double, int, int*, int*, char *);
>  char *	fcvtbuf (double, int, int*, int*, char *);
>  char *	ecvtf (float,int,int *,int *);
>  #endif
> +#ifndef __CYGWIN__
>  char *	__itoa (int, char *, int);
>  char *	__utoa (unsigned, char *, int);
> -#if __MISC_VISIBLE
> +# if __MISC_VISIBLE
>  char *	itoa (int, char *, int);
>  char *	utoa (unsigned, char *, int);
> +# endif
>  #endif
>  #if __POSIX_VISIBLE
>  int	rand_r (unsigned *__seed);
> -- 
> 2.43.0
> 

In fact, while this patch fixes the namespace pollution for Cygwin, I
wonder if we shouldn't remove itoa/utoa entirely.  The underscored
functions __itoa/__utoa accomplish exactly the same thing.

Does anybody actually *need* itoa/utoa as long as we have __itoa/__utoa?


Corinna
  

>
> ------------------------------
> *From:* Corinna Vinschen <vinschen@redhat.com>
> *Sent:* Tuesday, January 23, 2024 4:03 AM
> *To:* Christian Franke <Christian.Franke@t-online.de>
> *Cc:* newlib@sourceware.org <newlib@sourceware.org>
> *Subject:* Re: Hide non-standard itoa/utoa() in stdlib.h or drop these
> functions?
>
>
> 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.
> >
> > See the original posts on the Cygwin list for more details:
> > https://sourceware.org/pipermail/cygwin/2024-January/255216.html
> > https://sourceware.org/pipermail/cygwin/2024-January/255217.html
> >
> > Corinna proposed to either drop these functions entirely or hide the
> > prototypes on Cygwin only. I attached a patch for the second alternative.
> >
> > --
> > Regards,
> > Christian
> >
>
> > From 5f1c43796c6a125f04c1f2436fc1048783ce3b7a Mon Sep 17 00:00:00 2001
> > From: Christian Franke <christian.franke@t-online.de>
> > Date: Mon, 22 Jan 2024 19:11:20 +0100
> > Subject: [PATCH] Hide itoa, utoa, __itoa and __utoa in stdlib.h on
> Cygwin only
> >
> > These functions are non-standard and not exported by Cygwin.
> >
> > Signed-off-by: Christian Franke <christian.franke@t-online.de>
> > ---
> >  newlib/libc/include/stdlib.h | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/newlib/libc/include/stdlib.h b/newlib/libc/include/stdlib.h
> > index 15b349440..fd89f5ba7 100644
> > --- a/newlib/libc/include/stdlib.h
> > +++ b/newlib/libc/include/stdlib.h
> > @@ -221,11 +221,13 @@ char *  ecvtbuf (double, int, int*, int*, char *);
> >  char *       fcvtbuf (double, int, int*, int*, char *);
> >  char *       ecvtf (float,int,int *,int *);
> >  #endif
> > +#ifndef __CYGWIN__
> >  char *       __itoa (int, char *, int);
> >  char *       __utoa (unsigned, char *, int);
> > -#if __MISC_VISIBLE
> > +# if __MISC_VISIBLE
> >  char *       itoa (int, char *, int);
> >  char *       utoa (unsigned, char *, int);
> > +# endif
> >  #endif
> >  #if __POSIX_VISIBLE
> >  int  rand_r (unsigned *__seed);
> > --
> > 2.43.0
> >
>
> In fact, while this patch fixes the namespace pollution for Cygwin, I
> wonder if we shouldn't remove itoa/utoa entirely.  The underscored
> functions __itoa/__utoa accomplish exactly the same thing.
>
> Does anybody actually *need* itoa/utoa as long as we have __itoa/__utoa?
>
>
> Corinna
>
>      itoa() and utoa() should definitely be deleted.
     Removing them from the header file is only a half-baked solution for
regular Newlib because they are still in the library.  With them still in
the library you can end up linking to the wrong version and that's worse
than the "wrong" prototype being found that clearly blows up compilation.
Given the __ versions still being available it allows a simple fix for
anyone that does happen to use them.  (Perhaps to be most friendly to that
we should somehow make sure that a point in the next release notes mentions
this.  (Won't be bad to find with the __ versions still in stdlib.h,
though.))
     (In hindsight we probably fell down on the job allowing them to be
added as they were.  Just the __ versions should have gone in to begin
with.)
                                              Craig
  

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.
>>
>> See the original posts on the Cygwin list for more details:
>> https://sourceware.org/pipermail/cygwin/2024-January/255216.html
>> https://sourceware.org/pipermail/cygwin/2024-January/255217.html
>>
>> Corinna proposed to either drop these functions entirely or hide the
>> prototypes on Cygwin only. I attached a patch for the second alternative.

>>  From 5f1c43796c6a125f04c1f2436fc1048783ce3b7a Mon Sep 17 00:00:00 2001
>> From: Christian Franke <christian.franke@t-online.de>
>> Date: Mon, 22 Jan 2024 19:11:20 +0100
>> Subject: [PATCH] Hide itoa, utoa, __itoa and __utoa in stdlib.h on Cygwin only
>>
>> These functions are non-standard and not exported by Cygwin.
>>
>> Signed-off-by: Christian Franke <christian.franke@t-online.de>
>> ---
>>   newlib/libc/include/stdlib.h | 4 +++-
>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/newlib/libc/include/stdlib.h b/newlib/libc/include/stdlib.h
>> index 15b349440..fd89f5ba7 100644
>> --- a/newlib/libc/include/stdlib.h
>> +++ b/newlib/libc/include/stdlib.h
>> @@ -221,11 +221,13 @@ char *	ecvtbuf (double, int, int*, int*, char *);
>>   char *	fcvtbuf (double, int, int*, int*, char *);
>>   char *	ecvtf (float,int,int *,int *);
>>   #endif
>> +#ifndef __CYGWIN__
>>   char *	__itoa (int, char *, int);
>>   char *	__utoa (unsigned, char *, int);
>> -#if __MISC_VISIBLE
>> +# if __MISC_VISIBLE
>>   char *	itoa (int, char *, int);
>>   char *	utoa (unsigned, char *, int);
>> +# endif
>>   #endif
>>   #if __POSIX_VISIBLE
>>   int	rand_r (unsigned *__seed);
>> -- 
>> 2.43.0

> In fact, while this patch fixes the namespace pollution for Cygwin, I
> wonder if we shouldn't remove itoa/utoa entirely.  The underscored
> functions __itoa/__utoa accomplish exactly the same thing.
> 
> 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.

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.

Downstream systems should note the change in their lists of supported functions, 
and in their release notes.
  

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.
>>>
>>> See the original posts on the Cygwin list for more details:
>>> https://sourceware.org/pipermail/cygwin/2024-January/255216.html
>>> https://sourceware.org/pipermail/cygwin/2024-January/255217.html
>>>
>>> Corinna proposed to either drop these functions entirely or hide the
>>> prototypes on Cygwin only. I attached a patch for the second 
>>> alternative.
>
>>>  From 5f1c43796c6a125f04c1f2436fc1048783ce3b7a Mon Sep 17 00:00:00 2001
>>> From: Christian Franke <christian.franke@t-online.de>
>>> Date: Mon, 22 Jan 2024 19:11:20 +0100
>>> Subject: [PATCH] Hide itoa, utoa, __itoa and __utoa in stdlib.h on 
>>> Cygwin only
>>>
>>> These functions are non-standard and not exported by Cygwin.
>>>
>>> Signed-off-by: Christian Franke <christian.franke@t-online.de>
>>> ---
>>>   newlib/libc/include/stdlib.h | 4 +++-
>>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/newlib/libc/include/stdlib.h 
>>> b/newlib/libc/include/stdlib.h
>>> index 15b349440..fd89f5ba7 100644
>>> --- a/newlib/libc/include/stdlib.h
>>> +++ b/newlib/libc/include/stdlib.h
>>> @@ -221,11 +221,13 @@ char *    ecvtbuf (double, int, int*, int*, 
>>> char *);
>>>   char *    fcvtbuf (double, int, int*, int*, char *);
>>>   char *    ecvtf (float,int,int *,int *);
>>>   #endif
>>> +#ifndef __CYGWIN__
>>>   char *    __itoa (int, char *, int);
>>>   char *    __utoa (unsigned, char *, int);
>>> -#if __MISC_VISIBLE
>>> +# if __MISC_VISIBLE
>>>   char *    itoa (int, char *, int);
>>>   char *    utoa (unsigned, char *, int);
>>> +# endif
>>>   #endif
>>>   #if __POSIX_VISIBLE
>>>   int    rand_r (unsigned *__seed);
>>> -- 
>>> 2.43.0
>
>> In fact, while this patch fixes the namespace pollution for Cygwin, I
>> wonder if we shouldn't remove itoa/utoa entirely.  The underscored
>> functions __itoa/__utoa accomplish exactly the same thing.
>>
>> 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


> 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.
>
> Downstream systems should note the change in their lists of supported 
> functions, and in their release notes.

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.
  

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.

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?


Corinna
  

On 2024-01-24 04:16, 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.

We do have some - Cygwin, RTEMS - others should note!
  

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.
  

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

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
  

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
>
  

On Jan 29 15:17, Christian Franke wrote:
> 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.
> ...

Good point.


Corinna
  

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.
> 
> See the original posts on the Cygwin list for more details:
> https://sourceware.org/pipermail/cygwin/2024-January/255216.html
> https://sourceware.org/pipermail/cygwin/2024-January/255217.html
> 
> Corinna proposed to either drop these functions entirely or hide the
> prototypes on Cygwin only. I attached a patch for the second alternative.
> 
> -- 
> Regards,
> Christian
> 

> From 5f1c43796c6a125f04c1f2436fc1048783ce3b7a Mon Sep 17 00:00:00 2001
> From: Christian Franke <christian.franke@t-online.de>
> Date: Mon, 22 Jan 2024 19:11:20 +0100
> Subject: [PATCH] Hide itoa, utoa, __itoa and __utoa in stdlib.h on Cygwin only
> 
> These functions are non-standard and not exported by Cygwin.
> 
> Signed-off-by: Christian Franke <christian.franke@t-online.de>
> ---
>  newlib/libc/include/stdlib.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Pushed.

Thanks,
Corinna