Re: [PATCH] print extended assertion failures to stderr

[Jonathan Wakely <jwakely@redhat.com>]

On Thu, 4 Nov 2021 at 11:30, Jonathan Wakely <jwakely@redhat.com> wrote:

>
>
> On Wed, 27 Oct 2021 at 09:27, Jay Feldblum via Libstdc++ <
> libstdc++@gcc.gnu.org> wrote:
>
>> From: yfeldblum <yfeldblum@gmail.com>
>>
>> The stdout stream is reserved for output intentionally produced by the
>> application. Assertion failures and other forms of logging must be
>> emitted to stderr, not to stdout.
>>
>> It is common for testing and monitoring infrastructure to scan stderr
>> for errors, such as for assertion failures, and to collect or retain
>> them for analysis or observation. It is a norm that assertion failures
>> match this expectation in practice.
>>
>> While `__builtin_fprintf` is available as a builtin, there is no
>> equivalent builtin for `stderr`. The only option in practice is to use
>> the macro `stderr`, which requires `#include <cstdio>`. It is desired
>> not to add such an include to `bits/c++config` so the solution is to
>> write and export a function which may be called by `bits/c++config`.
>>
>> This is expected to be API-compatible and ABI-compatible with caveats.
>> Code compiled against an earlier libstdc++ will work when linked into a
>> later libstdc++ but the stream to which assertion failures are logged is
>> anybody's guess, and in practice will be determined by the link line and
>> the choice of linker. This fix targets builds for which all C++ code is
>> built against a libstdc++ with the fix.
>>
>
> Thanks for the patch! Comments below.
>
>
>
>>
>> Alternatives:
>> * This, which is the smallest change.
>> * This, but also defining symbols `std::__stdin` and `std::__stdout` for
>>   completeness.
>> * Define a symbol like `std::__printf_stderr` which prints any message
>>   with any formatting to stderr, just as `std::printf` does to stdout,
>>   and call that from `std::__replacement_assert` instead of calling
>>   `__builtin_printf`.
>> * Move `std::__replacement_assert` into libstdc++.so and no longer mark
>>   it as weak. This allows an application with some parts built against a
>>   previous libstdc++ to guarantee that the fix will be applied at least
>>   to the parts that are built against a libstdc++ containing the fix.
>>
>
Actually it wouldn't guarantee it even for the new parts. Any objects built
against the old libstdc++ headers might contain a definition of
std::__replacement_assert, and that would get used in preference to the one
in libstdc++.so, even for the new objects built against the new headers. To
make it work we could change the signature of the function (e.g. use long
or unsigned instead of int for the line number) so that code compiled
against the new headers look for a new symbol, and never use one in old
objects.