Re: Hide non-standard itoa/utoa() in stdlib.h or drop these functions?

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.
> 
> -- 
> Regards,
> Christian
> 

> 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?


Corinna