From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) by sourceware.org (Postfix) with ESMTPS id A99043858032 for ; Wed, 19 Jan 2022 02:39:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A99043858032 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-qt1-x832.google.com with SMTP id v7so978568qtw.13 for ; Tue, 18 Jan 2022 18:39:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=SfmIUpbhM4ekEzforduYDTIVY0pFMJNm2zslhl/ssdE=; b=nbPP4gy9p3fKm3Eilb+zFw7v2bAjev8pSc1Rnd5CQT8Cp+7h/CqGGhRks/DDAzjMtZ Sx9mwQJlZl8IazEsfat9xovIJ2/Jdg8kpFxodAv19epjjmM3H79R+KVOd8NdiUfSL/uj bFJE0jVadtMlZAG6+m+MSl9XwApLZQUi9rnVcyzUn/0xJ+rIzZxnIawvYrax12Aj8C7k d+kOLeyjjm6bmHFLDN+EetcN+pSbu0oQr+NSOL92p1b/TKJU5t/SlAQGHOBqDzqaCRlS KoTCCutFrambIDyRqlS8s0eioqi71cqCc06CAq+k2lOsG0ItAnEb4VNtN180nGwGzzUg MJHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=SfmIUpbhM4ekEzforduYDTIVY0pFMJNm2zslhl/ssdE=; b=Xxf/gwZWapXreZFqPPLLwAcfY4U2EgkvaN/fBAcruXgEMv1hTfrWSmM/sAxtdqDcxU WyrHgfCbGYCcn3TJCorfcg3alVSQYpJgg46m8I9deP6ghwvQ8oUF/vGXmEgywHM8CqNh WH2vqCsqPiO8BLhq6pspgm1d3d41x2q+9Rqpg7CD/y8VVJM7AZ+0qz/+5aeympaAfvLN o0a4P78hK5Zop0GFj79zZgEYbCx/HtrD56WpujgUCGS6UEjC75s7JonjwgX9HJQxjU7x MO20hWkxGiqhYkl+go9onTao0ZY+smgSysiF+Xc69U5ZtMbCNK90UTjPr8DlsGAko0eN ONtQ== X-Gm-Message-State: AOAM530EoXa3mA0fTNKKlNjBa1qpIV6zgCissQCTDzOil8IUGMkyjtAh DSQ1dqqo/gxSX2ccmnZfRZ0yfYTmCzwpQUXhuDU+u+M= X-Google-Smtp-Source: ABdhPJxVhjEvy8YDGCDL0prdjAYXwbtdQ1FnK3DeFylRKtp2RWoeGyHN+tJLzhrcNBJzF4WwNsRFaQe+cEUAa6O5X48= X-Received: by 2002:a05:622a:198a:: with SMTP id u10mr21411369qtc.109.1642559989179; Tue, 18 Jan 2022 18:39:49 -0800 (PST) MIME-Version: 1.0 References: <20220118044741.21027-1-vapier@gentoo.org> <20220118044741.21027-2-vapier@gentoo.org> In-Reply-To: From: C Howland Date: Tue, 18 Jan 2022 21:39:38 -0500 Message-ID: Subject: Re: [PATCH 1/8] newlib: internalize HAVE_INITFINI_ARRAY To: newlib@sourceware.org X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, LIKELY_SPAM_BODY, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 02:39:51 -0000 On Tue, 18 Jan 2022 at 19:53, Mike Frysinger wrote: > 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 > 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. Yes, agreed, it is violating preprocessor namespace. 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.) Craig