From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26383 invoked from network); 18 Feb 2023 12:17:32 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 18 Feb 2023 12:17:32 -0000 Received: (qmail 31786 invoked by uid 550); 18 Feb 2023 12:17:27 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 31751 invoked from network); 18 Feb 2023 12:17:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=zziw+fCHCrVV2drmwZ2lj59ZlSckqkfk+0Hs663zvPM=; b=Uf1T09lytLKhdMq5wGlMUlhXT52zcAL1z0v8KctsWxMQv5e4x3NbC6mQliZhbTKJwG LTkWZW0z3yExVeverQoOJWR7pkGq0OI5LxOHri0RCNSne8aW4zSRna4IyE3cTGZYYh6K XJ3MwdCtFk4qJbCHyTCFA8rVA27nq9wgl4QO7Fqlk7ZD5F6icnBFpqtK6qXeVcEzbOrM yJIyenxlpJrDTdQB8uMwUJ9zNCI81mGaCKsU56H2QttgeoAwClhr2bsxwrZ9qrwU7OCW oT0gaQTyHr7qqAkSLx+DwvEBX3CO4MXL21AGXd4qKMxUl+7q+U7oVNuQqJKoWIDRMpu2 SPWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=zziw+fCHCrVV2drmwZ2lj59ZlSckqkfk+0Hs663zvPM=; b=Pq1gUir0FwGMICkjrgHxUtK6kkYj6GG8O4057+OER1ycYbmMqMC7wCRshFE9D04Los a9MQ1rQHMMzIEO7XMveyI9UdYTQMq+E0b3BZQCIB/LGj4XkOIXu1So6lzcxW8LlgxL9H /Mh7sW7xMO9mu7SEmKpSh47nzB9n+Y3xr6eLgWwz3t3qau5y4/uOXwuwuvCVU/W1Rgmh t5RN0hwfT0Y5wzrc7Ay/zar4kzA1Ki3K8geEjln9k+1c4gglgxnhmo6hattoH+Fn64Ra xnQeXdxIsjXu2F//bbIGtehkeYdnIsOcRaoS4N01bITT+recLjZ/QbcmeqX3iOMLbBdd rLjQ== X-Gm-Message-State: AO0yUKWJtY4eKTqaIeVWDbqKoQIpdiObS8srXAMK4G3bpZyS1lE/3H2z 1U5orTW+Q8ZncmlFCXfpiwFgLeQuVYnIiondCJ5SJIOB X-Google-Smtp-Source: AK7set/J5z/d5omsdgDL0WcLiCHSK0eybnoGCETG9xBph2PZFG/pVYgmUgWL74kjtYiyvUetML1a+jgT2xjJCXDR6Vs= X-Received: by 2002:a81:ae57:0:b0:52e:e095:d840 with SMTP id g23-20020a81ae57000000b0052ee095d840mr38472ywk.0.1676722634394; Sat, 18 Feb 2023 04:17:14 -0800 (PST) MIME-Version: 1.0 References: <20230218013333.844224-1-i@maskray.me> <20230218020320.GA4163@brightrain.aerifal.cx> In-Reply-To: From: Jon Chesterfield Date: Sat, 18 Feb 2023 12:17:03 +0000 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000028f4905f4f8692e" Subject: Re: [musl] [PATCH] Use __builtin_FILE/__builtin_LINE if available --000000000000028f4905f4f8692e Content-Type: text/plain; charset="UTF-8" On Sat, 18 Feb 2023, 02:54 Fangrui Song, wrote: On Fri, Feb 17, 2023 at 6:03 PM Rich Felker wrote: > > On Fri, Feb 17, 2023 at 05:33:33PM -0800, Fangrui Song wrote: > > C++ inline functions are requred to have exact same sequence of tokens > > in every translation unit, but __FILE__ and __LINE__ may expand to > > different tokens. The ODR violatioin is usually benign, but it can lead > > to errors when C++20 modules are used. It is sad that C++ modules broke 'assert' but not surprising. Modules were largely created out of aversion to macros. This isn't something libc can fix though, I suggest a defect report against C++ instead. Changing the semantics of assert in C seems like a bad thing to do. Thanks --000000000000028f4905f4f8692e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, 18 Feb 2023, 0= 2:54 Fangrui Song, <i@maskray.me>= wrote:
On Fri, Feb 17= , 2023 at 6:03 PM Rich Felker <dalias= @libc.org> wrote:
>
> On Fri, Feb 17, 2023 at 05:33:33PM= -0800, Fangrui Song wrote:
> > C++ inline functions are requred t= o have exact same sequence of tokens
> > in every translation unit= , but __FILE__ and __LINE__ may expand to
> > different tokens. Th= e ODR violatioin is usually benign, but it can lead
> > to errors = when C++20 modules are used.


It is sad that C++ modules broke 'asser= t' but not surprising. Modules were largely created out of aversion to = macros. This isn't something libc can fix though, I suggest a defect re= port against C++ instead.

Chan= ging the semantics of assert in C seems like a bad thing to do.

Thanks
--000000000000028f4905f4f8692e--