From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) by sourceware.org (Postfix) with ESMTPS id 6485E3858D28 for ; Tue, 18 Jan 2022 16:10:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6485E3858D28 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-x831.google.com with SMTP id c19so22619190qtx.3 for ; Tue, 18 Jan 2022 08:10:56 -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=83cRIGrZ017wIHULdvn3/vFMRfeI+LPoZ+hTiVLkBNw=; b=TqAPyKodVjibrVlDtwXuY1wZZCDG03A7xsJdUKtEAsm7QaGkGhbUEXgiEIbwR7o0yY xiYZMJw2YUBTfP1Uwaf3s0LXSE7xoFJR21bXWzJ5gAuq5MQhVkfcXB/rb6quN10POQQ1 TcU4cxYRhL2Dncqs9o92cQs1hfZe3sqKbtvXzX4BvpVJGYTwA9WethjCizuHZIa7SaDq LNhIQcvjx8QXPlUz2ZfnPWFJAbwccXgEo777sY7vTJxlJOPxYiPCS7ADAE83yXO4mgQJ 0PJHNCOjEzREgv4yOW1VjiOEPR49TVz6w2l03NzLIfikfnXu0YoyJEHUL+ub1D53U606 34lg== 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=83cRIGrZ017wIHULdvn3/vFMRfeI+LPoZ+hTiVLkBNw=; b=YcYebWmPfXEVGpgsfnmq3ib/xroekPv2sej3Q0FsdPs7R2q43XvxbAOwD3wAnSFkGi n2//TIZ4czVFPlTd6mEfnsbyNdIts6MJsgGRsOV2o9GKfu5F7GKv23Ml1CsYKgt/yUBF 80U9fkDwYIIIL2azixWKiNgjGK3fO3Wdp/ndYPr7hVG7UJTWDaeV4xyZRANnmmcY56fb LMvsyZoUXKQKf2TFVFrHWB4u99Q2r/XD3uTkn4mDT1Ebqlf0tEw4kc951lSB/ONMQgJK dHf86foPyvn5w0rbdnZ5kaHE2qjG4hU46T1mhH+B5ZCtv3xXGMUADzBlif15hupY/ZiA GjEw== X-Gm-Message-State: AOAM532SAGxT7fQt6kRZJm/3MjntmE+j+z3LdQ77At+Qd+DixNTKCje8 tOux/hGApQSFD7uUizp/cW70xAf0yBjyJOxYg/YT+y8= X-Google-Smtp-Source: ABdhPJwCPgZV2yWXf9d5RRyRXVQohYQjpe5u9aHKIzJWZbHSzuc8DRei3sZmiGGOg+/z0Ooo0PE1GNH+MTkt4aXJVkQ= X-Received: by 2002:ac8:5c51:: with SMTP id j17mr2647106qtj.367.1642522255892; Tue, 18 Jan 2022 08:10:55 -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 11:10:44 -0500 Message-ID: Subject: Re: Fw: [PATCH 1/8] newlib: internalize HAVE_INITFINI_ARRAY To: newlib@sourceware.org X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Tue, 18 Jan 2022 16:10:59 -0000 > ------------------------------ > *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.) Craig