public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: brian.inglis@systematicsw.ab.ca
To: newlib@sourceware.org
Subject: Re: Hide non-standard itoa/utoa() in stdlib.h or drop these functions?
Date: Tue, 23 Jan 2024 14:41:09 -0700	[thread overview]
Message-ID: <a622f515-4c99-4de1-8cb2-0248d9e40054@systematicsw.ab.ca> (raw)
In-Reply-To: <Za-A11pBFk_BPMbg@calimero.vinschen.de>

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.

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.

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

  parent reply	other threads:[~2024-01-23 21:41 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 [this message]
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
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=a622f515-4c99-4de1-8cb2-0248d9e40054@systematicsw.ab.ca \
    --to=brian.inglis@systematicsw.ab.ca \
    --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).