From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 1BE02385E448 for ; Wed, 24 Jan 2024 11:16:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1BE02385E448 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1BE02385E448 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706095009; cv=none; b=Lu2PsNE6iqBXGFO1xIYd12tdRHHvQQ87UdZaBLvTh1dUTk46wP6GPb5qYBTBxmJuHkwcoG4OtJNizBryqQbuJ9oLfDL/8ZuyFvDWSy4uvKO5awdLZIlEbrWaiy+MxBha12xaMhNHokDyIMev09XIgRiQaeTVnEMD1n9PK7auUEo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706095009; c=relaxed/simple; bh=gdThTXxFnNh3r4Kq4pgFXy75xgC7ReIrY0FXm1j25U8=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=MnJ37GbThYPDNmRTs8XZp40katFDw7XHDVYW0M1IwlGId36D9AYxQYXGorvbnD2+1P/Ep+TgXyUfm3qF25hWsVGF5lp2BaS/29LORrmaCNZHij1GldUoqD+shVqlXlaAVGtiY5lYVZwDiGuuVuRIgsb9K2t66fV9OB0DqV/l7FE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1706095006; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bD4/MRHcZebogsoUTd13lWm3sNPOrPx+9L4Gd5gaPHA=; b=d22Q5uq0YwjprHXxVOXaGJmBFwkJNKX2ozeY183hSG+aPCBlhI/+funeRJLuGnPqL0uzaQ ICykV3CfmbjCdoajRXXQWy7EqLQLmKQ5xshCznW5rPgGcWC3diLcR8LRU7mQuyGmNc2vlU +YlxYZFDStfhhwu+VUnBPpPIGbAvBoM= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-197-mk3NRYOFO9-ftp87E-He1A-1; Wed, 24 Jan 2024 06:16:42 -0500 X-MC-Unique: mk3NRYOFO9-ftp87E-He1A-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A402185A597 for ; Wed, 24 Jan 2024 11:16:42 +0000 (UTC) Received: from calimero.vinschen.de (unknown [10.39.192.49]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8370C51D5 for ; Wed, 24 Jan 2024 11:16:42 +0000 (UTC) Received: by calimero.vinschen.de (Postfix, from userid 500) id 04199A80B93; Wed, 24 Jan 2024 12:16:40 +0100 (CET) Date: Wed, 24 Jan 2024 12:16:40 +0100 From: Corinna Vinschen To: newlib@sourceware.org Subject: Re: Hide non-standard itoa/utoa() in stdlib.h or drop these functions? Message-ID: Reply-To: newlib@sourceware.org Mail-Followup-To: newlib@sourceware.org References: <83962310-aec8-a718-bafb-6e10703693b8@t-online.de> <90bedd49-bed9-0c6d-fd89-a94241b0dd4f@t-online.de> MIME-Version: 1.0 In-Reply-To: <90bedd49-bed9-0c6d-fd89-a94241b0dd4f@t-online.de> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,BODY_8BITS,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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: 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. 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? Corinna