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

[Corinna Vinschen <vinschen@redhat.com>]

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