From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id 01EC43858032 for ; Wed, 19 Jan 2022 00:53:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 01EC43858032 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 42012342FB0; Wed, 19 Jan 2022 00:53:19 +0000 (UTC) Date: Tue, 18 Jan 2022 19:53:20 -0500 From: Mike Frysinger To: C Howland Cc: newlib@sourceware.org Subject: Re: Fw: [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="o6jzRLJST9UL9G/1" Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, LIKELY_SPAM_BODY, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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 00:53:22 -0000 --o6jzRLJST9UL9G/1 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On 18 Jan 2022 11:10, C Howland wrote: > > ------------------------------ > > *From:* Newlib on > > 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 defined > 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 would > require runtime to find out.) > This does not necessarily mean that this specific change ought not be > done, but it does mean that this consideration needs to be weighed before > an API-breaking change were made. Offhand I can't think of a good way to > guard against it, either. (A tedious way would be to mark it deprecated > 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 the toolchain will warn. we can put a note in the docs/NEWS, but that requires people actually read them. and if they're reading those, then we can just 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 here. if an actual user comes out of the woodworks, we can consider whether it's worth adding it, and in the right namespace. -mike --o6jzRLJST9UL9G/1 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmHnYP8ACgkQQWM7n+g3 9YFj2hAA2JJ46RVxTVPi1S+v1lhDzdSh+3Ivvn/jkJSdAOcgo6tG2fl3B+iy7PTy iH8Q/ASvA5CjgLA1eGbEOxenAca1e8D5qwXXtEjw7c5Rz+ADWglxcXnKQPG4kgGP 3YpICB5ou3vEm/Z6qXiUEhx9lL6x+HwRumbYW12yL5QGZ2WNMZ0FE9HwqJq4XxqJ mhHx8igd1mrk95AvDSyhFGwTknjTZx4+fQ36vS4BmXsESCEzWUg3CdhMqzOlh/WK HP9DAY+H7BKEpGlBrmQ8Lk1qM75yMIXual+ugBmUlCf5uSKnUc6rb4K8JVIftGf8 BGAbtWwPRL/xuCUfm4y5mbCMfWa9D8mMA2sEjZHP6i1xvl4m8KlZx204WptvruBk iCyNMmT6NiyWrLN5/kID2X4iDLi0b8k1Sorl3RYudSnRk72Zapj+jYej2iWx85dW /+SEDTf9SK8pJYdxO5650xNPuUWbil/ev5zMYUzt5yXUOpZFH+JGt7thFPuMC1gf AJksFlHuis26X32HgBLBYeUKrVBf9hIloerJC4oBtijdRys5E77rw+OVrUa3q7+i mCOIJFrShIJAHaCV2fB3g4sDy8/u4pQ0xTNzXrzhMGRqYfxtD4zNXBHg+hLt4eXT QrSWV5LpBxO+AvUvVk+K5FTnnwDaDEkHmsUvzmYhwNzeYlA/U0I= =h3v4 -----END PGP SIGNATURE----- --o6jzRLJST9UL9G/1--