Fw: [PATCH 1/8] newlib: internalize HAVE_INITFINI_ARRAY

[Mike Frysinger]

On 18 Jan 2022 11:10, C Howland wrote:
> > ------------------------------
> > *From:* Newlib <newlib-bounces+craig.howland=caci.com@sourceware.org> on
> > behalf of Mike Frysinger <vapier@gentoo.org>
> > *Sent:* Monday, January 17, 2022 11:47 PM
> > *To:* newlib@sourceware.org <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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/newlib/attachments/20220118/6be7003b/attachment.sig>