public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
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


  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).