From: Mike Frysinger <vapier@gentoo.org>
To: C Howland <cc1964t@gmail.com>
Cc: newlib@sourceware.org
Subject: Re: Fw: [PATCH 1/8] newlib: internalize HAVE_INITFINI_ARRAY
Date: Tue, 18 Jan 2022 19:53:20 -0500 [thread overview]
Message-ID: <YedhAMkqDBgJI/R8@vapier> (raw)
In-Reply-To: <CANk6obSOonWJ+2XvDt9ZSpyBqOkWO1PyWzFDF5x+QXWFCf9Hmg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2505 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-01-19 0:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-18 4:47 [PATCH 0/8] newlib: convert newlib.h to autoheader Mike Frysinger
2022-01-18 4:47 ` [PATCH 1/8] newlib: internalize HAVE_INITFINI_ARRAY Mike Frysinger
[not found] ` <DM3P110MB0522248DFEE102BB37B43A8F9A589@DM3P110MB0522.NAMP110.PROD.OUTLOOK.COM>
2022-01-18 16:10 ` Fw: " C Howland
2022-01-19 0:53 ` Mike Frysinger [this message]
2022-01-19 2:39 ` C Howland
2022-01-19 3:44 ` Mike Frysinger
2022-01-19 23:50 ` Mike Frysinger
2022-01-18 4:47 ` [PATCH 2/8] newlib: merge acconfig.h changes into newlib.hin Mike Frysinger
2022-01-18 4:47 ` [PATCH 3/8] newlib: clean up autoheader templates Mike Frysinger
2022-01-18 4:47 ` [PATCH 4/8] newlib: sort newlib.h output Mike Frysinger
2022-01-18 4:47 ` [PATCH 5/8] newlib: move version defines out of the config headers Mike Frysinger
2022-01-18 4:47 ` [PATCH 6/8] newlib: add missing _NANO_MALLOC to newlib.hin Mike Frysinger
2022-01-18 4:47 ` [PATCH 7/8] newlib: iconv: autogenerate iconv define list Mike Frysinger
2022-01-18 4:47 ` [PATCH 8/8] newlib: switch newlib.h to autoheader Mike Frysinger
2022-01-19 14:51 ` [PATCH 0/8] newlib: convert " Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YedhAMkqDBgJI/R8@vapier \
--to=vapier@gentoo.org \
--cc=cc1964t@gmail.com \
--cc=newlib@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).