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

[Corinna Vinschen]

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