From: Corinna Vinschen <vinschen@redhat.com>
To: Christian Franke <Christian.Franke@t-online.de>
Cc: newlib@sourceware.org
Subject: Re: Hide non-standard itoa/utoa() in stdlib.h or drop these functions?
Date: Mon, 29 Jan 2024 13:56:11 +0100 [thread overview]
Message-ID: <Zbega_5suC86to9N@calimero.vinschen.de> (raw)
In-Reply-To: <0cbff769-04c0-210b-e832-9886fb252da6@t-online.de>
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
next prev parent reply other threads:[~2024-01-29 12:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 18:46 Christian Franke
2024-01-23 9:03 ` Corinna Vinschen
[not found] ` <BN2P110MB154497B2775D2D45D55C91009A74A@BN2P110MB1544.NAMP110.PROD.OUTLOOK.COM>
2024-01-23 16:05 ` Fw: " C Howland
2024-01-23 21:41 ` brian.inglis
2024-01-24 9:42 ` Christian Franke
2024-01-24 11:16 ` Corinna Vinschen
2024-01-24 18:08 ` brian.inglis
2024-01-28 12:52 ` Christian Franke
2024-01-29 12:56 ` Corinna Vinschen [this message]
2024-01-29 14:17 ` Christian Franke
2024-01-29 15:31 ` Corinna Vinschen
2024-01-31 19:08 ` Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zbega_5suC86to9N@calimero.vinschen.de \
--to=vinschen@redhat.com \
--cc=Christian.Franke@t-online.de \
--cc=newlib@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).