From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout10.t-online.de (mailout10.t-online.de [194.25.134.21]) by sourceware.org (Postfix) with ESMTPS id 0BE613858402 for ; Mon, 29 Jan 2024 14:17:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0BE613858402 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 0BE613858402 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=194.25.134.21 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706537867; cv=none; b=vBs+ccv1xdl5pbGOMdW/Ia0m96P/hx1FSm3eH2U4YCmpGooV2CvwyaQZKdw4OdG35YV2h50xDP3C/m1OoxqhD5JcnBAnYxiiV8oMrFGd2sSXaRK7DNKt6s/XGDtmjgSsOrB8fYIY+V5EmSKxlPFjAb8giFfhKeZOK2Sv52wW7EE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706537867; c=relaxed/simple; bh=mV3he4W0gRqs0L247sN9+yHEcMgY5ZnBlbfiWLh7Jnk=; h=Subject:To:From:Message-ID:Date:MIME-Version; b=W/Q+W1oS/TKMg9K8r1VsnbS90AL/ekv6gTSW3iya9lUDTmpNEEmLn9XxbAVrrutth0YholjnyZDMmGr0sK4YA92eKdHWB9KcTP5Y/GaccwlpOc1b2TYm1lbuEqdBlfo950pKELT7FZ9prkZO+iTkmrIV1lFqqS7LZOcluuF1nGM= 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 mailout10.t-online.de (Postfix) with SMTP id D97DD41622 for ; Mon, 29 Jan 2024 15:17:34 +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 1rUSS6-0Us9RY0; Mon, 29 Jan 2024 15:17:34 +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> <0cbff769-04c0-210b-e832-9886fb252da6@t-online.de> From: Christian Franke Message-ID: <15262111-fb6b-41a4-9da6-9533b7a98f16@t-online.de> Date: Mon, 29 Jan 2024 15:17:33 +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: 7bit X-TOI-EXPURGATEID: 150726::1706537854-D5FF893F-16845298/0/0 CLEAN NORMAL X-TOI-MSGID: 967181bd-8a84-487d-a385-7294299e9c85 X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KAM_DMARC_STATUS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H5,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 28 13:52, Christian Franke wrote: >> Corinna Vinschen wrote: >>>>>>> [...] >>>>>> Does anybody actually *need* itoa/utoa as long as we have __itoa/__utoa? >>>>> [...] >>> 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. > I never doubted that. My question is NOT how we can keep itoa/utoa > alive and striving. I think we have really only two ways of going > forward: > > #if __CYGWIN__'ize itoa/utoa prototypes in stdlib.h, but DO NOT > #if __CYGWIN__'ize __itoa/__utoa, because they are living in > reserved namespace anyway The DO NOT branch would only make real sense if Cygwin would provide the __*() functions, As this is not the case, my patch disables also these prototypes. ... > or > > drop the definitions of itoa/utoa from itoa.c and utoa.c, drop the > prototypes from stdlib.h, but NEITHER drop __itoa/__utoa from > the source files NOR drop their prototypes. > > I favor the second approach, but if we can't get this sorted out > within the next two days, we'll go ahead with the first approach. > > > Corinna >