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

2023-10-08 Thread llvm at rifkin dot dev via Gcc-bugs
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

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

2023-10-08 Thread llvm at rifkin dot dev via Gcc-bugs
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

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

2023-10-08 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130 Andrew Pinski changed: What|Removed |Added CC||llvm at rifkin dot dev --- Comment #19

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

2023-07-10 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0

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

2023-07-09 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130 Andrew Pinski changed: What|Removed |Added CC||mimomorin at gmail dot com --- Comment

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

2018-06-13 Thread p.sanders at alpinesoft dot co.uk
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

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

2018-06-13 Thread redi at gcc dot gnu.org
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

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

2018-06-13 Thread redi at gcc dot gnu.org
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.

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

2018-06-13 Thread redi at gcc dot gnu.org
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

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

2018-06-13 Thread p.sanders at alpinesoft dot co.uk
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

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

2018-06-13 Thread p.sanders at alpinesoft dot co.uk
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

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

2018-06-13 Thread msebor at gcc dot gnu.org
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

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

2018-06-13 Thread redi at gcc dot gnu.org
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

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

2018-06-13 Thread p.sanders at alpinesoft dot co.uk
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

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

2018-06-13 Thread redi at gcc dot gnu.org
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

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

2018-06-13 Thread redi at gcc dot gnu.org
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

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

2018-06-13 Thread redi at gcc dot gnu.org
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. ***

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

2018-06-13 Thread p.sanders at alpinesoft dot co.uk
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

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

2018-06-13 Thread redi at gcc dot gnu.org
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

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

2018-06-13 Thread p.sanders at alpinesoft dot co.uk
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