From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id AAD203857C53 for ; Wed, 19 Jan 2022 03:44:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AAD203857C53 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org Received: by smtp.gentoo.org (Postfix, from userid 559) id D16D63431E8; Wed, 19 Jan 2022 03:44:03 +0000 (UTC) Date: Tue, 18 Jan 2022 22:44:04 -0500 From: Mike Frysinger To: C Howland Cc: newlib@sourceware.org Subject: Re: [PATCH 1/8] newlib: internalize HAVE_INITFINI_ARRAY Message-ID: Mail-Followup-To: C Howland , newlib@sourceware.org References: <20220118044741.21027-1-vapier@gentoo.org> <20220118044741.21027-2-vapier@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NasFM8Xxl/K0C5C8" Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, LIKELY_SPAM_BODY, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2022 03:44:06 -0000 --NasFM8Xxl/K0C5C8 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 18 Jan 2022 21:39, C Howland wrote: > On Tue, 18 Jan 2022 at 19:53, Mike Frysinger wrote: > > On 18 Jan 2022 11:10, C Howland wrote: > > > > behalf of Mike Frysinger > > > > *Sent:* Monday, January 17, 2022 11:47 PM > > > > *To:* newlib@sourceware.org > > > > *Subject:* [PATCH 1/8] newlib: internalize HAVE_INITFINI_ARRAY > > > > > > > > This define is only used by newlib internally, so stop exporting it > > > > as HAVE_INITFINI_ARRAY since this can conflict with defines packages > > > > use themselves. > > > > > > > > We don't really need to add _ to HAVE_INIT_FINI too since it isn't > > > > exported in newlib.h, but might as well be consistent here. > > > > > > How do you know it is only used by Newlib internally? Changing = this > > > is effectively changing the API and is not safe. (I don't use it, > > myself, > > > but given it's been like this for a long time, there's nothing to say > > that > > > nobody is.) Unfortunately, it uses a methodology as either being def= ined > > > or not, so someone using the #ifdef method on it would not immediately > > > notice the change. (That is, when building with something that looked= at > > > it, the build itself could not know something had gone wrong. It wou= ld > > > require runtime to find out.) > > > This does not necessarily mean that this specific change ought n= ot > > be > > > done, but it does mean that this consideration needs to be weighed be= fore > > > an API-breaking change were made. Offhand I can't think of a good wa= y to > > > guard against it, either. (A tedious way would be to mark it depreca= ted > > > and then remove it in a year or so.) > > > > any project relying on this is broken. exporting this symbol violates > > standards > > as to the namespace C libraries are allowed to use. in fact, a cursory > > search > > shows that it is breaking projects because they were using this define, > > but the > > newlib symbol override their configure tests leading to desyncs. > > > > we also don't export HAVE_INIT_FINI, so newlib users aren't able to > > determine > > how newlib is actually going to behave at run time. > > > > there is no way to mark a preprocessor symbol as deprecated such that t= he > > toolchain will warn. we can put a note in the docs/NEWS, but that requ= ires > > people actually read them. and if they're reading those, then we can j= ust > > as easily put mention that the symbol has been removed. > > > > i really don't think this is a big deal. arguing theory isn't useful h= ere. > > > > if an actual user comes out of the woodworks, we can consider whether i= t's > > worth adding it, and in the right namespace. >=20 > There is no exporting of HAVE_INIT_FINI as it is a preprocessor > define. All the user has to do it to include newlib.h and they see it (or > fail to see it). (I think we might have a word-choice difference here. > It's a preprocessor define, and is only of local file scope at > preprocessing time. You can't "export" the variable to another file, it > only comes directly from newlib.h.) But this is unrelated to the primary > point I'm making. i think you got confused by my point. my patch is about the HAVE_INITFINI_= ARRAY macro. i followed up pointing out that newlib also leverages HAVE_INIT_FINI internally, but doesn't make that state visible externally. hence anyone w= ho tries to leverage HAVE_INITFINI_ARRAY is already getting an incomplete pict= ure. preprocessor directives create macros, not variables. i understand that "exporting" isn't a thing here, and isn't the same as "extern" or other C- level storage/linkage. i'm referring to general concepts, not to specific standards language, and i'm being lazy and imprecise as a result. i don't think we need to get into a pointless semantic debate here. > I'm not arguing just theory. I am pointing out that this changes API > (albeit at the preprocessor level instead of the more usual linkage level) > and we are always very careful when API is changed. If this case is one = in > which changing it is OK, fine. We just need to consciously make that > decision; my intent in writing is only that we directly make the choice > instead of falling sideways into it. (You clearly think this one is worth > it. I happen to agree, but that's not that important because it's > generally practice for Corinna or Jeff to OK this class of change.) i understand your points. i disagree that removing this symbol will have a= ny meaningful impact, and that any code that might actually break deserves any consideration for using something it shouldn't have in the first place. -mike --NasFM8Xxl/K0C5C8 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmHniQQACgkQQWM7n+g3 9YGNARAA0mXZnbHhf69b3SQfY0lWrJqVtFWK2NDRw1VQD3z+lE5TEKXF0KmxL8Q2 rGhxM2USc/kdfTw29RRZB7iw5APi25R8zuWIctuGkcEk6Q2VK4KezbJ6/kIo3vst DcwiRff6rLhs46l90hMWPBwwxAsOm8c6iIPqMn8lHFqSxKJpqZk8sbLaG7G4+qko tMoRJRgZq7qbulHGpbHDHyNFxyWABUqiIpGx/1WqgjSnrTnAFnHcuKeI0aWQRtIt +SR5ko+LcE98UDGvEpw+iJaMQWZT8NL5cnqA1se6CAKSaKt3Ya3BdmA/cbL/0eRw JbRATdx1eLzJ4z9D8HZdpmkUc/a3NftqzLgU9PfhXdb/zUewnBUEmiJl4hjLmwyB 9okLYXesFbM++FfUjNuMn2IAs/jqht8YFtC8wq1cgTTDFM+Si0D1TCQ/nrvFH0O8 OcnC3eLzumDHaTxhX8gIJ1zhFjBMmdjmI9omvD4xedcMYExnIO0SpsndahYax3ea sSwh+xwMUYECyiQ9S2L9/hM5PiGdWt/z8YCGhdg+DZF78rLZSeyps1FqINRAJ+6y Py+4N8HVY6NPFxJNx13YPeolcek4lYGV2JT/rT2FNwcjJ2woNzA9npFOfJHCHrbW YWc1aowC01MIEAmobdklVfuA0hh+MpUYaDITkbnozX96wgSF1Ms= =16fr -----END PGP SIGNATURE----- --NasFM8Xxl/K0C5C8--