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 <[email protected]>
>> 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 <[email protected]>
>> ---
>> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.