This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libstdc++/86130] Expect SIGSEGV but program just silently exits


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]