https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #21 from Jeremy R. ---
Another option might be just do nothing and don't set the badbit, just pretend
it's an empty string. This shouldn't break existing programs and would at least
be something a programmer could more easily track
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #20 from Jeremy R. ---
Silently ruining the behavior of the rest of a program and leaving the
programmer to pull their hair out over what on earth is happening seems very
un-ideal behavior.
This is a very easy mistake to make and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
Andrew Pinski changed:
What|Removed |Added
CC||llvm at rifkin dot dev
--- Comment #19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
Andrew Pinski changed:
What|Removed |Added
CC||mimomorin at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #16 from Paul Sanders ---
Interesting, I can see why you don't want to change the behaviour again. It's
just a shame it ever did anything other than SEGFAULT in the first place but as
you point out, it's been the way it is for a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #15 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #13)
> This is not an accident, it's a supported feature (and arguably documented,
> by the code and the test).
See also Bug 6518 which changed the segfault to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #14 from Jonathan Wakely ---
(In reply to Paul Sanders from comment #12)
> Any interest?
Good grief, no.
That would generate even worse code than what we have now, and it's possible to
test for badbit without enabling exceptions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #13 from Jonathan Wakely ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #12 from Paul Sanders ---
Sorry, I posted that in a bit of a rush. I took a proper look and the null
pointers that set badbit actually make excellent sense.
So I'll suggest a way out of the backwards compatibility conundrum when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #11 from Paul Sanders ---
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #10 from Martin Sebor ---
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) which doesn't have the same
feature (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #9 from Jonathan Wakely ---
(In reply to Paul Sanders from comment #8)
> Thanks for your comments. I can see there are two sides to this.
>
> I was in the middle of composing the tract below. I'll include that anyway
> because it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #8 from Paul Sanders ---
Thanks for your comments. I can see there are two sides to this.
I was in the middle of composing the tract below. I'll include that anyway
because it took me ages to type. There's a bit at the end about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #7 from Jonathan Wakely ---
I don't know the original reason for handling null pointers here, but it's
consistent with glibc's printf which prints "(null)" when a null pointer is
provided for a %s specifier.
Removing this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #6 from Jonathan Wakely ---
And they don't test for iostream operations failing?
The program has undefined behaviour, i.e. a bug. Whether it's better to
identify that and treat it as a corrupt stream state (setting badbit, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #5 from Jonathan Wakely ---
*** Bug 86129 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #4 from Paul Sanders ---
@Johnathon Crashing the program is the right thing to do, because it means that
the developer (or the test department) will get to find out about the problem
before the customer does.
Does that help you see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #3 from Jonathan Wakely ---
Arguably crashing the program is more unfriendly.
We could add the nonnull attribute to the relevant ostream members, or add
assertions that can be optionally enabled, but I'm not convinced that crashing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #2 from Paul Sanders ---
Hi Martin,
Thanks very much for your prompt reply, and I completely agree with your
viewpoint.
I therefore hereby request that libstc++ stops behaving like that and just lets
the SIGSEGV happen. The
20 matches
Mail list logo