Re: [patch] Use __builtin_FILE and __builtin_LINE in assert implementation in C++

[Jonathan Wakely <jwakely@redhat.com>]

On Tue, 24 Jan 2023 at 15:08, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>
> The 01/24/2023 12:17, Jonathan Wakely via Libc-alpha wrote:
> > On Tue, 24 Jan 2023 at 12:08, Florian Weimer <fweimer@redhat.com> wrote:
> > > There's also the issue that <cassert> is defined in terms of ISO C,
> > > and ISO C specifies that __FILE__ and __LINE__ must be used.  Is that
> > > another defect?  But maybe the difference is not observable because
> > > __FILE__ cannot be redefined?
> >
> > I don't think it's observable. C requires the text printed by a failed
> > assert to include "the values of the preprocessing macros __FILE__ and
> > __LINE__ " but it doesn't require the actual tokens to appear in the
> > definition. The built-ins do return "the values" of those macros, so
> > that seems OK to me.
>
> is that a real fix? the token sequence is the same in different
> TUs with the builtins but the actual printed path is different,
> so if the linker picks a definition at random then the produced
> binary is not deterministic.

In practice, that only happens if you copy & paste the inline function
definition so it appears in two different TUs. If the inline function
is defined in a header, as in 99.9% of cases, then __FILE__ and
__builtin_FILE() both give you the name of that header, and the
problem never happens anyway. If you do weird things (duplicating the
code so it appears in two separate TUs without being included by a
common header) and the inline function isn't inlined, then yes, some
calls might appear to come from the "other" definition, showing the
file and line number of that definition. C'est la vie.

> why is this better than just using __FILE__?

The version with __FILE__ has undefined behaviour, and might not even
compile in a strict implementation of C++20 modules.

The version with __builtin_FILE is valid C++, so required to compile.
You might still get non-deterministic output if you duplicate the code
(instead of defining it in a header), but that's also possible if you
have a function that prints the value of rand() in an assertion
message.

Valid code that has non-deterministic behaviour in weird use cases is
better than code that has undefined behaviour in those cases.