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

On Jan 24 10:42, Christian Franke wrote:
> [email protected] 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