mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Szabolcs Nagy <nsz@port70.net>
To: Fangrui Song <i@maskray.me>
Cc: musl@lists.openwall.com
Subject: Re: [musl] [PATCH] Use __builtin_FILE/__builtin_LINE if available
Date: Mon, 27 Feb 2023 23:26:53 +0100	[thread overview]
Message-ID: <20230227222653.GI726682@port70.net> (raw)
In-Reply-To: <DS7PR12MB5765A4D1C26328E261EEE7ABCBA59@DS7PR12MB5765.namprd12.prod.outlook.com>

* Fangrui Song <i@maskray.me> [2023-02-21 11:09:14 -0800]:

> On Sat, Feb 18, 2023 at 4:17 AM Jon Chesterfield
> <jonathanchesterfield@gmail.com> wrote:
> >
> > On Sat, 18 Feb 2023, 02: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 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
> 
> I disagree. This is a footgun where the right fix (or workaround, if
> you prefer) is on the libc side. It is fairly reasonable for a header
> to use assert and not expect two includes using different paths to not
> cause C++ module problems.
> 
> The current module behavior regarding macros is a reasonable
> compromise. It can be evolved (e.g.
> https://gracicot.github.io/modules/2018/05/14/modules-macro.html).

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.)

libc can avoid printing the file path in the assert fail message for
c++. this makes assert less useful but it solves the conformance issue.
if c++ does not specify which path assert should print (or allow it to
be unpredictable) then it is difficult to do better than this.

it would have been more useful to have a __builtin_canonical_FILE()
or similar that gives a path that is somehow independent of include
path, but we don't have that now.

  reply	other threads:[~2023-02-27 22:27 UTC|newest]

Thread overview: 10+ 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 [this message]
2023-03-02  8:19           ` Fangrui Song
     [not found]           ` <DS7PR12MB57655F44D45FF7D0B9BB01C5CBB29@DS7PR12MB5765.namprd12.prod.outlook.com>
2023-03-05  3:23             ` Zhihao Yuan
2023-08-30 22:04               ` Fangrui Song
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20230227222653.GI726682@port70.net \
    --to=nsz@port70.net \
    --cc=i@maskray.me \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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

	https://git.vuxu.org/mirror/musl/

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).