From: Jonathan Wakely <jwakely@redhat.com>
To: Jay Feldblum <yfeldblum@gmail.com>
Cc: "libstdc++" <libstdc++@gcc.gnu.org>,
gcc Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] print extended assertion failures to stderr
Date: Thu, 4 Nov 2021 23:44:16 +0000 [thread overview]
Message-ID: <CACb0b4ngAFMoHUj=+zfV9tGWj0g3hfWNR1YWiXVW2H7zmGo55Q@mail.gmail.com> (raw)
In-Reply-To: <CACb0b4k4_Bgh-fMRWFWbQqbTC8QGvUOB=AoV=j9Ja-iXmBRshg@mail.gmail.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.
next prev parent reply other threads:[~2021-11-04 23:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-27 8:25 Jay Feldblum
2021-11-04 11:30 ` Jonathan Wakely
2021-11-04 23:44 ` Jonathan Wakely [this message]
2021-11-04 13:53 sotrdg sotrdg
2021-11-04 13:54 ` Jonathan Wakely
[not found] ` <CH2PR02MB65229EA7D6AA4BCC9515F087B28D9@CH2PR02MB6522.namprd02.prod.outlook.com>
[not found] ` <CACb0b4m7oddSaVMqDG61gDQ_++pC4nrJYRpPE3U6E+QRbyVNQA@mail.gmail.com>
2021-11-04 14:17 ` sotrdg sotrdg
2021-11-04 15:13 ` Jonathan Wakely
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='CACb0b4ngAFMoHUj=+zfV9tGWj0g3hfWNR1YWiXVW2H7zmGo55Q@mail.gmail.com' \
--to=jwakely@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=libstdc++@gcc.gnu.org \
--cc=yfeldblum@gmail.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.
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 read-only IMAP folder(s) and NNTP newsgroup(s).