This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/86130] Expect SIGSEGV but program just silently exits
- From: "redi at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 13 Jun 2018 21:31:28 +0000
- Subject: [Bug libstdc++/86130] Expect SIGSEGV but program just silently exits
- Auto-submitted: auto-generated
- References: <bug-86130-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #10)
> As a data point, calling printf ("%s", p) does lead to a segfault in Glibc
> for a null p because GCC turns the call into puts(p)
Only when optimization is enabled.
I'm not suggesting we should print "(null)", that would be crazy, I'm just
demonstrating that expecting a segfault for this kind of error is not a safe or
valid assumption.
> which doesn't have the
> same feature (see https://sourceware.org/bugzilla/show_bug.cgi?id=5618 for
> the background).
>
> I think most users prefer invalid uses of pointers to fail loudly so they
> can be caught early. Few users expect output functions to fail, and even
> fewer bother to check for failures when writing to standard streams.
Agreed, but this code has been present since r53839 in 2002, and there's an
explicit test for that behaviour:
testsuite/27_io/basic_ostream/inserters_character/char/8.cc
This is not an accident, it's a supported feature (and arguably documented, by
the code and the test).
> Besides the inserter without the test resulting in more efficient code and
> GCC emitting a warning when a null pointer is passed to it (it doesn't now
> even though it should because of the strlen call), leaving it to the
> compiler to deal with can also lead to better code downstream thanks to
> -fdelete-null-pointer-checks.
I think there would need to be a period of deprecation and an optional
assertion enabled by _GLIBCXX_ASSERTIONS before we can do that (assuming we
want to).
If we were starting from scratch I wouldn't add the check (e.g. see the patch
at https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00768.html that I proposed
today) but it's far too late to just turn this into a segfault because somebody
on stackoverflow found it surprising and doesn't know how to check iostreams
for errors.