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 29275 invoked from network); 5 Mar 2023 03:23:34 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 5 Mar 2023 03:23:34 -0000 Received: (qmail 30255 invoked by uid 550); 5 Mar 2023 03:23:30 -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 30216 invoked from network); 5 Mar 2023 03:23:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677986598; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=n4WPPQES9kgJ3sHgRbAP0ruVPMOCzUO/vnH32B13lBk=; b=giwpLgnzJy8oZ2vBc5GqSupyaBu3rSOl7GxRXU6lOtC3SeKNtlP9zK9eFv/pCkYCcS TZSvsg1Zk9Kq32fN8hHKbb9uwlx3RXcfZ3XwuYGK8H60W7yKoAlShR1BSRI6mwsYy6/Z Y+S64XkIKpreAl32a2QcoeoTR1hQJoLZYTo5QRfs1Wcz2fw8/4w540gXPf9Z8XlMMQH9 Av+GHmjiMupYGCL09PWNhvW/we5iAiMamLDWMwfkOwOTH7xJFz+oUcgpXkkhF8y6G9NT 6+sD9HcepW8SRD9vlsGrkJuK+G4tMr/3sShO3+Xl8e752YMfv4xyeR3jlZ8X7WQpyCv4 U02Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677986598; h=cc: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=n4WPPQES9kgJ3sHgRbAP0ruVPMOCzUO/vnH32B13lBk=; b=UlTiwyCd9Mp1PAcTnMZX2ApZN95nyY8FX6Rq+wrSGQAR9HryicKlqm4bt0fd/gNH/5 VEsWsf3vL4P3ugLfQJs08yMPPvWSk+oXw9lipa220Ntza3/EnX74Huhk2OWCOPAPzrVQ LvqQD2jEg6sSepY5b2dCsl9AP294XbvPv/iWJjnwK6lA2v6t47L41EzUkopvq5sRpG/t taCN6o8/1gLUDBEgytOYsZdqyOmfvoogjjnUHzvjNQemMwkxLGYlof08SV6xhyk9XFDl VkT+FpQbxi9v9mgrCs4bIV3pIpvxwqoGmP0PMopkQlQHjeDVaY358jGB+Xh+Yrh13tIx 1lMg== X-Gm-Message-State: AO0yUKXRQQ2CUzVCmZm07LRrYXnI+LLbIVS457qtFiowNnhtHdCTYZ4S nsb84ywvw6Bv8eD8zRvVBZLWrb8YD6PBg9RIC0g= X-Google-Smtp-Source: AK7set+ZSo0Pxyq4r6oTPt2wTU+kr34X7amr3NOwZWyNxuAMeBvGX6NLuOYiyLYbu8juSPc4aiq21u4HJFq1N0Mll4k= X-Received: by 2002:a5d:4d8d:0:b0:2c7:a39:78ae with SMTP id b13-20020a5d4d8d000000b002c70a3978aemr1181043wru.13.1677986597633; Sat, 04 Mar 2023 19:23:17 -0800 (PST) MIME-Version: 1.0 References: <20230218013333.844224-1-i@maskray.me> <20230218020320.GA4163@brightrain.aerifal.cx> <20230227222653.GI726682@port70.net> In-Reply-To: From: Zhihao Yuan Date: Sat, 4 Mar 2023 19:23:21 -0800 Message-ID: To: Fangrui Song Cc: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="00000000000017042f05f61eb3bf" Subject: Re: [musl] [PATCH] Use __builtin_FILE/__builtin_LINE if available --00000000000017042f05f61eb3bf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 2, 2023 at 12:19 AM Fangrui Song wrote: > On Mon, Feb 27, 2023 at 2:27=E2=80=AFPM Szabolcs Nagy wr= ote: > > > > 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. > > To lichray: ^^ > The definition of 'assert' is mandatory only when NDEBUG is defined as a macro name. 7.2.1.1 reads: "[...], if expression (which shall have a scalar type) is false (that is, compares equal to 0), the assert macro writes information about the particular call that failed (including the text of the argument, the name of the source file, the source line number, and the name of the enclosing function =E2=80=94 the latter are respectively the values of the preprocessing macro= s __FILE__ and __LINE__ and of the identifier __func__) on the standard error stream in an implementation-defined format." The text in parentheses did not mandate the use of __FILE__ and __LINE__, and C++ did not permit 'assert' not to work in modules. Therefore an implementation that fails to compile the code snippet in the original email is not conforming. > > > > > Changing the semantics of assert in C seems like a bad thing to do. > > > > > The semantics is unchanged, and people are doing it: Add custom ODR-safe assert. (!1166) =C2=B7 Merge requests =C2=B7 libeigen /= eigen =C2=B7 GitLab > > > > i dont see how that solves the fundamental problem: > > > > the *behavior* of assert changes depending on which include path is > > used and thus inline functions that are supposed to be equivalent > > aren't. (__builtin_FILE makes the pp-token sequence the same across > > the instances, but the actual code will have different paths, which > > while not an odr violation per the literal words of the spec, it > > clearly violates the reason the rule is there in the first place.) > This is a different topic. In related news, CWG Issue 2678 (cplusplus.github.io) will likely need to be revisited (i.e., what does 'odr' mean is subject to change). Regardless, __builtin_FILE is a vendor extension and serves customers' needs in implementing 'assert.' --=20 Zhihao Yuan, ID lichray The best way to predict the future is to invent it. _______________________________________________ --00000000000017042f05f61eb3bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Mar 2, 2023 at 12:19 AM Fangrui S= ong <i@maskray.me> wrote:
On Mon, Feb 27, 2023 at 2:27=E2=80=AFPM Szabolcs Nagy <nsz@port70.net> wrote:
>= ; > > It is sad that C++ modules broke 'assert' but not surpr= ising. Modules were largely created out of aversion to macros. This isn'= ;t something libc can fix though, I suggest a defect report against C++ ins= tead.

To lichray: ^^

The definition of 'a= ssert' is mandatory only when=C2=A0NDEBUG
is defined as a mac= ro name. 7.2.1.1 reads:

"[...], if expression= (which shall have a scalar type) is false (that is, compares equal to 0),<= br>the assert macro writes information about the particular call that faile= d (including the text of the
argument, the name of the source file, the = source line number, and the name of the enclosing function
=E2=80=94 the= latter are respectively the values of the preprocessing macros __FILE__ an= d __LINE__ and of
the identifier __func__) on the standard error stream = in an implementation-defined format."

The= text in parentheses=C2=A0did not mandate the use of __FILE__
and= __LINE__, and C++ did not permit 'assert' not to work in
modules. Therefore an implementation that fails to compile
the c= ode snippet in the original email is not conforming.

> > > Changing the semantics of assert in C seems like a bad thing= to do.
> > >

The semantics is unchang= ed, and people are doing it:

=C2=A0
&g= t;
> i dont see how that solves the fundamental problem:
>
> the *behavior* of assert changes depending on which include path is > used and thus inline functions that are supposed to be equivalent
> aren't. (__builtin_FILE makes the pp-token sequence the same acros= s
> the instances, but the actual code will have different paths, which > while not an odr violation per the literal words of the spec, it
> clearly violates the reason the rule is there in the first place.)
=

This is a different topic. In relate= d news,=C2=A0C= WG Issue 2678 (cplusplus.github.io)
will likely need to be re= visited (i.e., what does 'odr' mean
is subject=C2=A0to ch= ange). Regardless, __builtin_FILE is
a vendor extension and serve= s customers' needs in
implementing 'assert.'

--
Zhihao Yuan, ID lichray
The best way to predict the future is t= o invent it.
_______________________________________________
--00000000000017042f05f61eb3bf--