mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Zhihao Yuan <>
To: Fangrui Song <>
Subject: Re: [musl] [PATCH] Use __builtin_FILE/__builtin_LINE if available
Date: Sat, 4 Mar 2023 19:23:21 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 2508 bytes --]

On Thu, Mar 2, 2023 at 12:19 AM Fangrui Song <> wrote:

> On Mon, Feb 27, 2023 at 2:27 PM Szabolcs Nagy <> wrote:
> > > > 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. 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
— the latter are respectively the values of the preprocessing macros
__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) · Merge requests · libeigen / eigen ·
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
( <>
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.'

Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.

[-- Attachment #2: Type: text/html, Size: 3559 bytes --]

  parent reply	other threads:[~2023-03-05  3:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-18  1:33 Fangrui Song
2023-02-18  2:03 ` Rich Felker
2023-02-18  2:53   ` Fangrui Song
2023-02-18 12:17     ` Jon Chesterfield
2023-02-21 19:09       ` Fangrui Song
2023-02-27 22:26         ` Szabolcs Nagy
2023-03-02  8:19           ` Fangrui Song
     [not found]           ` <>
2023-03-05  3:23             ` Zhihao Yuan [this message]
2023-02-21 19:45       ` Jeffrey Walton

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \

* 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.
Code repositories for project(s) associated with this public inbox

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 NNTP newsgroup(s).