From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout03.t-online.de (mailout03.t-online.de [194.25.134.81]) by sourceware.org (Postfix) with ESMTPS id 166833858C60 for ; Sun, 28 Jan 2024 12:52:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 166833858C60 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=t-online.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=t-online.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 166833858C60 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=194.25.134.81 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706446332; cv=none; b=R78y77DoQ5x9kOns+q6h0B7GOWAb6V6h1r2X5dD/zcR/HlSN2+DaYS0v/bhWC7lWZ07v3Ol3i1cylon+ElnwJSVzlc9qa4Bz4dbXGHc36z17xNi0FZACDLP2aR5Jf7uds9n2qcs0PpfeVrRc6mhnU4tlzeg5vzfR4ts5Nxy8zMI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706446332; c=relaxed/simple; bh=ZS6DGKfp0ZUVow0JrumKLMGU+Iv6H9df1aYITDqE4/s=; h=Subject:To:From:Message-ID:Date:MIME-Version; b=fny0rL0JjwsoOTr+rZQjz4WsqBcsEHYUc4lDwcWU2nNK9xtobm9z1RxCX7Q80bFYmBI8/lT4fONPKpYqDdV83uk/sxQ9t3DfqcUSePNugMd3M5mneWzQEJ3S05iyvjDS8104CAEehDosEujDpfmSxchES7NeeqMgvmWnrkhzIf0= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from fwd74.aul.t-online.de (fwd74.aul.t-online.de [10.223.144.100]) by mailout03.t-online.de (Postfix) with SMTP id 605EF58AB for ; Sun, 28 Jan 2024 13:52:09 +0100 (CET) Received: from [192.168.2.104] ([79.230.174.55]) by fwd74.t-online.de with (TLSv1.3:TLS_AES_256_GCM_SHA384 encrypted) esmtp id 1rU4dr-1q1FJI0; Sun, 28 Jan 2024 13:52:07 +0100 Subject: Re: Hide non-standard itoa/utoa() in stdlib.h or drop these functions? To: newlib@sourceware.org References: <83962310-aec8-a718-bafb-6e10703693b8@t-online.de> <90bedd49-bed9-0c6d-fd89-a94241b0dd4f@t-online.de> From: Christian Franke Message-ID: <0cbff769-04c0-210b-e832-9886fb252da6@t-online.de> Date: Sun, 28 Jan 2024 13:52:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 SeaMonkey/2.53.16 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TOI-EXPURGATEID: 150726::1706446327-D7FFC93F-204D126D/0/0 CLEAN NORMAL X-TOI-MSGID: 98b61db8-5f87-4b11-9a5e-afb40c1f7011 X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,BODY_8BITS,FREEMAIL_FROM,KAM_DMARC_STATUS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Corinna Vinschen wrote: > On Jan 24 10:42, Christian Franke wrote: >> 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. >>>>> [...] >>>> 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 > Also, the fact that it has been mentioned in K&R was apparently no > incentive to standarize it later on. That's why its existence on > various systems is a bit erratic. > >>> 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. > Mind, I never said to remove the underscored functins. So the > functionality still exists, it's just called __foo instead of foo. > >>> Downstream systems should note the change in their lists of supported >>> functions, and in their release notes. > We don't have any influence on downstream, but if downstream wants the > API, it's easy to provide it by aliasing foo to __foo in a downstream > header. > >> 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. > The problem is that _GNU_SOURCE got synonymous for "everything and the > kitchen sink", and there's no blessed way around that other than > defining another source standard instead. My interpretation was "everything and the kitchen sink - except everything never provided by glibc or Linux" :-) > Do we really want to create our own kind of "this is > non-standard"-standard? > > That would be something like __NEWLIB_VISIBLE / _NEWLIB_SOURCE. > > But, then again, for just two seldom used APIs? The API is seldom used, possibly not or no longer well known and definitely unavailable in widely used other C libs. This increases the risk of a conflict with local functions with the same name. Busybox is a real world example. If it will be decided to keep this API as is, please consider to accept my patch from the start of this thread. It IMO obviously makes sense because Cygwin does not provide this API. This could at least simplify my patch for the busybox Cygwin package and may increase the probability that it will be accepted by busybox upstream.