From: Christian Franke <Christian.Franke@t-online.de>
To: newlib@sourceware.org
Subject: Re: Hide non-standard itoa/utoa() in stdlib.h or drop these functions?
Date: Wed, 24 Jan 2024 10:42:11 +0100 [thread overview]
Message-ID: <90bedd49-bed9-0c6d-fd89-a94241b0dd4f@t-online.de> (raw)
In-Reply-To: <a622f515-4c99-4de1-8cb2-0248d9e40054@systematicsw.ab.ca>
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.
--
Regards,
Christian
next prev parent reply other threads:[~2024-01-24 9:42 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 [this message]
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
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=90bedd49-bed9-0c6d-fd89-a94241b0dd4f@t-online.de \
--to=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).