public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/14493] New: new: No std::bad_alloc::what() const
@ 2004-03-08 22:10 debian-gcc at lists dot debian dot org
2004-03-08 22:37 ` [Bug libstdc++/14493] " pinskia at gcc dot gnu dot org
` (17 more replies)
0 siblings, 18 replies; 37+ messages in thread
From: debian-gcc at lists dot debian dot org @ 2004-03-08 22:10 UTC (permalink / raw)
To: gcc-bugs
[forwarded from http://bugs.debian.org/236912]
std::bad_alloc doesn't seem to define a what() (std par. 18.4.2.1)
leading to unintelligible error messages.
--
Summary: new: No std::bad_alloc::what() const
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] new: No std::bad_alloc::what() const
2004-03-08 22:10 [Bug libstdc++/14493] New: new: No std::bad_alloc::what() const debian-gcc at lists dot debian dot org
@ 2004-03-08 22:37 ` pinskia at gcc dot gnu dot org
2004-03-08 23:15 ` [Bug libstdc++/14493] " bangerth at dealii dot org
` (16 subsequent siblings)
17 siblings, 0 replies; 37+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-03-08 22:37 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-03-08 22:36 -------
Confirmed a bug, but it seems like the code you have should compile as exception have a what()
method.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed| |1
Last reconfirmed|0000-00-00 00:00:00 |2004-03-08 22:36:26
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] No std::bad_alloc::what() const
2004-03-08 22:10 [Bug libstdc++/14493] New: new: No std::bad_alloc::what() const debian-gcc at lists dot debian dot org
2004-03-08 22:37 ` [Bug libstdc++/14493] " pinskia at gcc dot gnu dot org
@ 2004-03-08 23:15 ` bangerth at dealii dot org
2004-03-09 4:14 ` pme at gcc dot gnu dot org
` (15 subsequent siblings)
17 siblings, 0 replies; 37+ messages in thread
From: bangerth at dealii dot org @ 2004-03-08 23:15 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From bangerth at dealii dot org 2004-03-08 23:15 -------
For Andrew: the code takes the respective method of the base
class.
Here's a testcase:
---------------
#include <iostream>
#include <new>
int main ()
{
try
{
new char[static_cast<unsigned int>(-1)/2];
}
catch (std::exception &e)
{
std::cerr << e.what () << std::endl;
}
}
----------------------
g/x> icc x.cc
g/x> ./a.out
bad allocation
g/x>
g/x> /home/bangerth/bin/gcc-3.5-pre/bin/c++ x.cc
g/x> ./a.out
St9bad_alloc
I believe that libstdc++ is actually conforming, since the method exists
(even if in the base class) and it returns an implementation defined
string (as required by the standard). Some of the libstdc++ folks should
comment on this.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] No std::bad_alloc::what() const
2004-03-08 22:10 [Bug libstdc++/14493] New: new: No std::bad_alloc::what() const debian-gcc at lists dot debian dot org
2004-03-08 22:37 ` [Bug libstdc++/14493] " pinskia at gcc dot gnu dot org
2004-03-08 23:15 ` [Bug libstdc++/14493] " bangerth at dealii dot org
@ 2004-03-09 4:14 ` pme at gcc dot gnu dot org
2004-03-09 4:14 ` phil at jaj dot com
` (14 subsequent siblings)
17 siblings, 0 replies; 37+ messages in thread
From: pme at gcc dot gnu dot org @ 2004-03-09 4:14 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pme at gcc dot gnu dot org 2004-03-09 04:14 -------
Works just fine. Submitter is mistaken.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] No std::bad_alloc::what() const
2004-03-08 22:10 [Bug libstdc++/14493] New: new: No std::bad_alloc::what() const debian-gcc at lists dot debian dot org
` (2 preceding siblings ...)
2004-03-09 4:14 ` pme at gcc dot gnu dot org
@ 2004-03-09 4:14 ` phil at jaj dot com
2004-03-09 4:45 ` zack at gcc dot gnu dot org
` (13 subsequent siblings)
17 siblings, 0 replies; 37+ messages in thread
From: phil at jaj dot com @ 2004-03-09 4:14 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From phil at jaj dot com 2004-03-09 04:14 -------
Subject: Re: No std::bad_alloc::what() const
close 236912
thanks
This bug report reinforces my opinion that bug reports consisting of
claims of nonconformance, but not accompanied by a testcase, should be
immediately closed.
On Mon, Mar 08, 2004 at 11:15:05PM -0000, bangerth at dealii dot org wrote:
> For Andrew: the code takes the respective method of the base
> class.
More to the point, it doesn't matter how it's implemented, and the user
should not care. It only matters that
std::bad_alloc foo;
std::cerr << foo.what() << std::endl;
works, which the submitter didn't apparently try. Looking at the original
Debian bug report, there are no compiler error messages, just a "my code
doesn't do what I want it to do, so it must be your fault"-style complaint.
> I believe that libstdc++ is actually conforming, since the method exists
> (even if in the base class)
Correct. There is no requirement on implementation, only behavior.
> and it returns an implementation defined
> string (as required by the standard).
Correct. As described in the documentation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] No std::bad_alloc::what() const
2004-03-08 22:10 [Bug libstdc++/14493] New: new: No std::bad_alloc::what() const debian-gcc at lists dot debian dot org
` (3 preceding siblings ...)
2004-03-09 4:14 ` phil at jaj dot com
@ 2004-03-09 4:45 ` zack at gcc dot gnu dot org
2004-03-09 5:19 ` doko at cs dot tu-berlin dot de
` (12 subsequent siblings)
17 siblings, 0 replies; 37+ messages in thread
From: zack at gcc dot gnu dot org @ 2004-03-09 4:45 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From zack at gcc dot gnu dot org 2004-03-09 04:45 -------
It appears to me that the original reporter wanted what() to return
an "intelligible error message" a la icc's "bad allocation", rather
than "St9bad_alloc" (which does communicate the same information but
in a more cryptic fashion).
I do think there should be a place in the standard library for nice
friendly names for exceptions (think strerror()), but I don't know
if what() is that place.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] No std::bad_alloc::what() const
2004-03-08 22:10 [Bug libstdc++/14493] New: new: No std::bad_alloc::what() const debian-gcc at lists dot debian dot org
` (4 preceding siblings ...)
2004-03-09 4:45 ` zack at gcc dot gnu dot org
@ 2004-03-09 5:19 ` doko at cs dot tu-berlin dot de
2004-03-09 18:32 ` jtv at xs4all dot nl
` (11 subsequent siblings)
17 siblings, 0 replies; 37+ messages in thread
From: doko at cs dot tu-berlin dot de @ 2004-03-09 5:19 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From doko at cs dot tu-berlin dot de 2004-03-09 05:19 -------
Subject: Re: No std::bad_alloc::what() const
[resending for the inclusion to the Debian BTS]
Phil Edwards writes:
> close 236912
> thanks
>
> This bug report reinforces my opinion that bug reports consisting of
> claims of nonconformance, but not accompanied by a testcase, should be
> immediately closed.
>
>
> On Mon, Mar 08, 2004 at 11:15:05PM -0000, bangerth at dealii dot org wrote:
> > For Andrew: the code takes the respective method of the base
> > class.
>
> More to the point, it doesn't matter how it's implemented, and the user
> should not care. It only matters that
>
> std::bad_alloc foo;
> std::cerr << foo.what() << std::endl;
>
> works, which the submitter didn't apparently try. Looking at the original
> Debian bug report, there are no compiler error messages, just a "my code
> doesn't do what I want it to do, so it must be your fault"-style complaint.
>
>
> > I believe that libstdc++ is actually conforming, since the method exists
> > (even if in the base class)
>
> Correct. There is no requirement on implementation, only behavior.
>
> > and it returns an implementation defined
> > string (as required by the standard).
>
> Correct. As described in the documentation.
>
>
> --
> To UNSUBSCRIBE, email to debian-gcc-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] No std::bad_alloc::what() const
2004-03-08 22:10 [Bug libstdc++/14493] New: new: No std::bad_alloc::what() const debian-gcc at lists dot debian dot org
` (5 preceding siblings ...)
2004-03-09 5:19 ` doko at cs dot tu-berlin dot de
@ 2004-03-09 18:32 ` jtv at xs4all dot nl
2004-03-09 19:32 ` phil at jaj dot com
` (10 subsequent siblings)
17 siblings, 0 replies; 37+ messages in thread
From: jtv at xs4all dot nl @ 2004-03-09 18:32 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From jtv at xs4all dot nl 2004-03-09 18:32 -------
Subject: Re: No std::bad_alloc::what() const
On Tue, Mar 09, 2004 at 06:14:59AM +0100, Matthias Klose wrote:
> > More to the point, it doesn't matter how it's implemented, and the user
> > should not care. It only matters that
> >
> > std::bad_alloc foo;
> > std::cerr << foo.what() << std::endl;
> >
> > works, which the submitter didn't apparently try. Looking at the original
Apparently whoever said this hasn't seen the bug report, and it got
rephrased somewhere along the line. I was wrong in my assumption that
std::bad_alloc should override what(), but the problem remains: the
message coming out of what(), "St9bad_alloc" is incomprehensible to
a normal user.
Jeroen
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] No std::bad_alloc::what() const
2004-03-08 22:10 [Bug libstdc++/14493] New: new: No std::bad_alloc::what() const debian-gcc at lists dot debian dot org
` (6 preceding siblings ...)
2004-03-09 18:32 ` jtv at xs4all dot nl
@ 2004-03-09 19:32 ` phil at jaj dot com
2004-03-09 19:48 ` pme at gcc dot gnu dot org
` (9 subsequent siblings)
17 siblings, 0 replies; 37+ messages in thread
From: phil at jaj dot com @ 2004-03-09 19:32 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From phil at jaj dot com 2004-03-09 19:32 -------
Subject: Re: Bug#236912: No std::bad_alloc::what() const
On Tue, Mar 09, 2004 at 07:32:32PM +0100, Jeroen T. Vermeulen wrote:
> On Tue, Mar 09, 2004 at 06:14:59AM +0100, Matthias Klose wrote:
>
> > > More to the point, it doesn't matter how it's implemented, and the user
> > > should not care. It only matters that
> > >
> > > std::bad_alloc foo;
> > > std::cerr << foo.what() << std::endl;
> > >
> > > works, which the submitter didn't apparently try. Looking at the original
>
> Apparently whoever said this hasn't seen the bug report, and it got
> rephrased somewhere along the line.
No, I read it.
> I was wrong in my assumption that
> std::bad_alloc should override what(), but the problem remains: the
> message coming out of what(), "St9bad_alloc" is incomprehensible to
> a normal user.
If you mean to complain about X, then don't complain about Y. Don't title
your bug reports "Y is missing" when you find you don't like the behavior
of X. Don't assume that X and Y have anything to do with one another.
The output of what() is described in the library documentation. There is
also documentation provided on how to run the demangler on the string, e.g.,
std::cerr << the_demangler_function(foo.what()) << std::endl;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] No std::bad_alloc::what() const
2004-03-08 22:10 [Bug libstdc++/14493] New: new: No std::bad_alloc::what() const debian-gcc at lists dot debian dot org
` (7 preceding siblings ...)
2004-03-09 19:32 ` phil at jaj dot com
@ 2004-03-09 19:48 ` pme at gcc dot gnu dot org
2004-03-09 20:14 ` Zack Weinberg
2004-03-09 20:14 ` zack at codesourcery dot com
` (8 subsequent siblings)
17 siblings, 1 reply; 37+ messages in thread
From: pme at gcc dot gnu dot org @ 2004-03-09 19:48 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pme at gcc dot gnu dot org 2004-03-09 19:48 -------
(In reply to comment #5)
> It appears to me that the original reporter wanted what() to return
> an "intelligible error message" a la icc's "bad allocation", rather
> than "St9bad_alloc" (which does communicate the same information but
> in a more cryptic fashion).
>
> I do think there should be a place in the standard library for nice
> friendly names for exceptions (think strerror()), but I don't know
> if what() is that place.
Slap a _Z on that thing and we could demangle it automatically. The
problems with doing so are that the demangling routines are linked in
when they otherwise wouldn't be (so goes the argument, but I haven't
verified it myself).
Personally, I feel __cxa_demangler should just be present, full stop.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Bug libstdc++/14493] No std::bad_alloc::what() const
2004-03-09 19:48 ` pme at gcc dot gnu dot org
@ 2004-03-09 20:14 ` Zack Weinberg
0 siblings, 0 replies; 37+ messages in thread
From: Zack Weinberg @ 2004-03-09 20:14 UTC (permalink / raw)
To: gcc-bugzilla; +Cc: gcc-bugs
"pme at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:
>> It appears to me that the original reporter wanted what() to return
>> an "intelligible error message" a la icc's "bad allocation", rather
>> than "St9bad_alloc" (which does communicate the same information but
>> in a more cryptic fashion).
>
> Slap a _Z on that thing and we could demangle it automatically. The
> problems with doing so are that the demangling routines are linked in
> when they otherwise wouldn't be (so goes the argument, but I haven't
> verified it myself).
Honestly, is "std::bad_alloc" really that much more readable than
"St9bad_alloc"? Especially compared to "bad allocation"?
zw
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] No std::bad_alloc::what() const
2004-03-08 22:10 [Bug libstdc++/14493] New: new: No std::bad_alloc::what() const debian-gcc at lists dot debian dot org
` (8 preceding siblings ...)
2004-03-09 19:48 ` pme at gcc dot gnu dot org
@ 2004-03-09 20:14 ` zack at codesourcery dot com
2004-03-10 1:12 ` giovannibajo at libero dot it
` (7 subsequent siblings)
17 siblings, 0 replies; 37+ messages in thread
From: zack at codesourcery dot com @ 2004-03-09 20:14 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From zack at codesourcery dot com 2004-03-09 20:14 -------
Subject: Re: No std::bad_alloc::what() const
"pme at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:
>> It appears to me that the original reporter wanted what() to return
>> an "intelligible error message" a la icc's "bad allocation", rather
>> than "St9bad_alloc" (which does communicate the same information but
>> in a more cryptic fashion).
>
> Slap a _Z on that thing and we could demangle it automatically. The
> problems with doing so are that the demangling routines are linked in
> when they otherwise wouldn't be (so goes the argument, but I haven't
> verified it myself).
Honestly, is "std::bad_alloc" really that much more readable than
"St9bad_alloc"? Especially compared to "bad allocation"?
zw
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] No std::bad_alloc::what() const
2004-03-08 22:10 [Bug libstdc++/14493] New: new: No std::bad_alloc::what() const debian-gcc at lists dot debian dot org
` (9 preceding siblings ...)
2004-03-09 20:14 ` zack at codesourcery dot com
@ 2004-03-10 1:12 ` giovannibajo at libero dot it
2004-03-11 7:35 ` pme at gcc dot gnu dot org
` (6 subsequent siblings)
17 siblings, 0 replies; 37+ messages in thread
From: giovannibajo at libero dot it @ 2004-03-10 1:12 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From giovannibajo at libero dot it 2004-03-10 01:12 -------
(In reply to comment #10)
> Honestly, is "std::bad_alloc" really that much more readable than
> "St9bad_alloc"? Especially compared to "bad allocation"?
Well, "St9bad_alloc" looks like memory corruption, unless you recognize it's
part of a mangled name. I think it is counter-intuitive. Of course, the best
would be to have a "bad allocation" string stored somewhere.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] No std::bad_alloc::what() const
2004-03-08 22:10 [Bug libstdc++/14493] New: new: No std::bad_alloc::what() const debian-gcc at lists dot debian dot org
` (10 preceding siblings ...)
2004-03-10 1:12 ` giovannibajo at libero dot it
@ 2004-03-11 7:35 ` pme at gcc dot gnu dot org
2004-03-11 10:05 ` gdr at integrable-solutions dot net
` (5 subsequent siblings)
17 siblings, 0 replies; 37+ messages in thread
From: pme at gcc dot gnu dot org @ 2004-03-11 7:35 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pme at gcc dot gnu dot org 2004-03-11 07:35 -------
> Honestly, is "std::bad_alloc" really that much more readable than
> "St9bad_alloc"?
The former is at least readable C++. More importantly, it's what 'new'
is documented as throwing, so a programmer reading (good) documentation
for operator new will see "std::bad_alloc".
> Especially compared to "bad allocation"?
Sure, we could change that. I don't think "bad allocation" is any
better than the demangled type name, but we shouldn't be printing
a mangled typeid. Others felt differently.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] No std::bad_alloc::what() const
2004-03-08 22:10 [Bug libstdc++/14493] New: new: No std::bad_alloc::what() const debian-gcc at lists dot debian dot org
` (11 preceding siblings ...)
2004-03-11 7:35 ` pme at gcc dot gnu dot org
@ 2004-03-11 10:05 ` gdr at integrable-solutions dot net
2004-03-11 15:51 ` bangerth at dealii dot org
` (4 subsequent siblings)
17 siblings, 0 replies; 37+ messages in thread
From: gdr at integrable-solutions dot net @ 2004-03-11 10:05 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From gdr at integrable-solutions dot net 2004-03-11 10:05 -------
Subject: Re: No std::bad_alloc::what() const
"pme at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:
| > Especially compared to "bad allocation"?
|
| Sure, we could change that. I don't think "bad allocation" is any
| better than the demangled type name, but we shouldn't be printing
| a mangled typeid. Others felt differently.
I agree with Phil that we should not have been printing the mangled
typeid.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] No std::bad_alloc::what() const
2004-03-08 22:10 [Bug libstdc++/14493] New: new: No std::bad_alloc::what() const debian-gcc at lists dot debian dot org
` (12 preceding siblings ...)
2004-03-11 10:05 ` gdr at integrable-solutions dot net
@ 2004-03-11 15:51 ` bangerth at dealii dot org
2004-03-11 15:52 ` bangerth at dealii dot org
` (3 subsequent siblings)
17 siblings, 0 replies; 37+ messages in thread
From: bangerth at dealii dot org @ 2004-03-11 15:51 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From bangerth at dealii dot org 2004-03-11 15:51 -------
The let's reopen the bug. I keep wondering why there is such resistance
to really small patches like the one needed for this PR...
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] No std::bad_alloc::what() const
2004-03-08 22:10 [Bug libstdc++/14493] New: new: No std::bad_alloc::what() const debian-gcc at lists dot debian dot org
` (13 preceding siblings ...)
2004-03-11 15:51 ` bangerth at dealii dot org
@ 2004-03-11 15:52 ` bangerth at dealii dot org
2004-04-27 13:54 ` [Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened pinskia at gcc dot gnu dot org
` (2 subsequent siblings)
17 siblings, 0 replies; 37+ messages in thread
From: bangerth at dealii dot org @ 2004-03-11 15:52 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From bangerth at dealii dot org 2004-03-11 15:52 -------
.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
2004-03-08 22:10 [Bug libstdc++/14493] New: new: No std::bad_alloc::what() const debian-gcc at lists dot debian dot org
` (14 preceding siblings ...)
2004-03-11 15:52 ` bangerth at dealii dot org
@ 2004-04-27 13:54 ` pinskia at gcc dot gnu dot org
2004-08-05 14:37 ` pcarlini at suse dot de
2004-08-05 15:01 ` pcarlini at suse dot de
17 siblings, 0 replies; 37+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-04-27 13:54 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
Severity|minor |enhancement
Status|REOPENED |NEW
Summary|No std::bad_alloc::what() |std::bad_alloc::what() does
|const |not explain what happened
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
2004-03-08 22:10 [Bug libstdc++/14493] New: new: No std::bad_alloc::what() const debian-gcc at lists dot debian dot org
` (15 preceding siblings ...)
2004-04-27 13:54 ` [Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened pinskia at gcc dot gnu dot org
@ 2004-08-05 14:37 ` pcarlini at suse dot de
2004-08-05 15:01 ` pcarlini at suse dot de
17 siblings, 0 replies; 37+ messages in thread
From: pcarlini at suse dot de @ 2004-08-05 14:37 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pcarlini at suse dot de 2004-08-05 14:37 -------
Implementing the trivial fix...
--
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
2004-03-08 22:10 [Bug libstdc++/14493] New: new: No std::bad_alloc::what() const debian-gcc at lists dot debian dot org
` (16 preceding siblings ...)
2004-08-05 14:37 ` pcarlini at suse dot de
@ 2004-08-05 15:01 ` pcarlini at suse dot de
17 siblings, 0 replies; 37+ messages in thread
From: pcarlini at suse dot de @ 2004-08-05 15:01 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pcarlini at suse dot de 2004-08-05 15:00 -------
... actually, not so trivial, because of the need to free the memory allocated
by __cxa_demangle :(
By the way, current Icc doesn't demangle anymore.
--
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu
| |dot org
Status|ASSIGNED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
[not found] <bug-14493-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2023-04-27 22:01 ` cvs-commit at gcc dot gnu.org
@ 2023-04-27 23:04 ` cvs-commit at gcc dot gnu.org
3 siblings, 0 replies; 37+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-04-27 23:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
--- Comment #33 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:
https://gcc.gnu.org/g:c73f20e67ee8d268bf0dfd6732c1bd3e79e098ca
commit r10-11323-gc73f20e67ee8d268bf0dfd6732c1bd3e79e098ca
Author: Jonathan Wakely <jwakely@redhat.com>
Date: Tue Apr 4 12:04:14 2023 +0100
libstdc++: Fix outdated docs about demangling exception messages
The string returned by std::bad_exception::what() hasn't been a mangled
name since PR libstdc++/14493 was fixed for GCC 4.2.0, so remove the
docs showing how to demangle it.
libstdc++-v3/ChangeLog:
* doc/xml/manual/extensions.xml: Remove std::bad_exception from
example program.
* doc/html/manual/ext_demangling.html: Regenerate.
(cherry picked from commit 688d126b69215db29774c249b052e52d765782b3)
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
[not found] <bug-14493-4@http.gcc.gnu.org/bugzilla/>
2023-04-04 11:17 ` cvs-commit at gcc dot gnu.org
2023-04-20 13:57 ` cvs-commit at gcc dot gnu.org
@ 2023-04-27 22:01 ` cvs-commit at gcc dot gnu.org
2023-04-27 23:04 ` cvs-commit at gcc dot gnu.org
3 siblings, 0 replies; 37+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-04-27 22:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
--- Comment #32 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:
https://gcc.gnu.org/g:ee1a8294754af16b00538b17414679c8d72a575b
commit r11-10660-gee1a8294754af16b00538b17414679c8d72a575b
Author: Jonathan Wakely <jwakely@redhat.com>
Date: Tue Apr 4 12:04:14 2023 +0100
libstdc++: Fix outdated docs about demangling exception messages
The string returned by std::bad_exception::what() hasn't been a mangled
name since PR libstdc++/14493 was fixed for GCC 4.2.0, so remove the
docs showing how to demangle it.
libstdc++-v3/ChangeLog:
* doc/xml/manual/extensions.xml: Remove std::bad_exception from
example program.
* doc/html/manual/ext_demangling.html: Regenerate.
(cherry picked from commit 688d126b69215db29774c249b052e52d765782b3)
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
[not found] <bug-14493-4@http.gcc.gnu.org/bugzilla/>
2023-04-04 11:17 ` cvs-commit at gcc dot gnu.org
@ 2023-04-20 13:57 ` cvs-commit at gcc dot gnu.org
2023-04-27 22:01 ` cvs-commit at gcc dot gnu.org
2023-04-27 23:04 ` cvs-commit at gcc dot gnu.org
3 siblings, 0 replies; 37+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-04-20 13:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
--- Comment #31 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:
https://gcc.gnu.org/g:e016a6ddbf0038056b9d8f2bc0bad350ff026632
commit r12-9456-ge016a6ddbf0038056b9d8f2bc0bad350ff026632
Author: Jonathan Wakely <jwakely@redhat.com>
Date: Tue Apr 4 12:04:14 2023 +0100
libstdc++: Fix outdated docs about demangling exception messages
The string returned by std::bad_exception::what() hasn't been a mangled
name since PR libstdc++/14493 was fixed for GCC 4.2.0, so remove the
docs showing how to demangle it.
libstdc++-v3/ChangeLog:
* doc/xml/manual/extensions.xml: Remove std::bad_exception from
example program.
* doc/html/manual/ext_demangling.html: Regenerate.
(cherry picked from commit 688d126b69215db29774c249b052e52d765782b3)
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
[not found] <bug-14493-4@http.gcc.gnu.org/bugzilla/>
@ 2023-04-04 11:17 ` cvs-commit at gcc dot gnu.org
2023-04-20 13:57 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 37+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-04-04 11:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
--- Comment #30 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:
https://gcc.gnu.org/g:688d126b69215db29774c249b052e52d765782b3
commit r13-6999-g688d126b69215db29774c249b052e52d765782b3
Author: Jonathan Wakely <jwakely@redhat.com>
Date: Tue Apr 4 12:04:14 2023 +0100
libstdc++: Fix outdated docs about demangling exception messages
The string returned by std::bad_exception::what() hasn't been a mangled
name since PR libstdc++/14493 was fixed for GCC 4.2.0, so remove the
docs showing how to demangle it.
libstdc++-v3/ChangeLog:
* doc/xml/manual/extensions.xml: Remove std::bad_exception from
example program.
* doc/html/manual/ext_demangling.html: Regenerate.
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
[not found] <bug-14493-5724@http.gcc.gnu.org/bugzilla/>
` (11 preceding siblings ...)
2007-02-01 15:57 ` paolo at gcc dot gnu dot org
@ 2007-02-01 15:58 ` pcarlini at suse dot de
12 siblings, 0 replies; 37+ messages in thread
From: pcarlini at suse dot de @ 2007-02-01 15:58 UTC (permalink / raw)
To: gcc-bugs
------- Comment #29 from pcarlini at suse dot de 2007-02-01 15:58 -------
Fixed.
--
pcarlini at suse dot de changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
[not found] <bug-14493-5724@http.gcc.gnu.org/bugzilla/>
` (10 preceding siblings ...)
2007-02-01 13:39 ` pcarlini at suse dot de
@ 2007-02-01 15:57 ` paolo at gcc dot gnu dot org
2007-02-01 15:58 ` pcarlini at suse dot de
12 siblings, 0 replies; 37+ messages in thread
From: paolo at gcc dot gnu dot org @ 2007-02-01 15:57 UTC (permalink / raw)
To: gcc-bugs
------- Comment #28 from paolo at gcc dot gnu dot org 2007-02-01 15:56 -------
Subject: Bug 14493
Author: paolo
Date: Thu Feb 1 15:56:37 2007
New Revision: 121465
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121465
Log:
2007-02-01 Paolo Carlini <pcarlini@suse.de>
PR libstdc++/14493
* libsupc++/typeinfo (bad_cast::what, bad_typeid::what): Declare.
* libsupc++/tinfo.cc: Define.
* libsupc++/exception (bad_exception::what): Declare.
* libsupc++/eh_exception.cc: Define.
(exception::what): Adjust, don't use typeid.
* libsupc++/new (bad_alloc::what): Declare.
* libsupc++/new_handler.cc: Define.
* config/abi/pre/gnu.ver: Export the new methods @3.4.9.
* testsuite/18_support/14493.cc: New.
2007-02-01 Paolo Carlini <pcarlini@suse.de>
PR libstdc++/29496
* include/debug/safe_base.h (_Safe_sequence_base::_M_get_mutex,
_Safe_iterator_base::_M_get_mutex, _M_attach_single, _M_detach_single):
New.
* src/debug.cc: Define the latter.
(_Safe_sequence_base::_M_detach_all, _M_detach_singular,
_M_revalidate_singular, _M_swap): Use the mutex.
(_Safe_iterator_base::_M_attach, _M_detach): Adjust, forward to the
*_single version.
* include/debug/safe_iterator.h (_Safe_iterator<>::_M_attach_single,
_M_invalidate_single): New.
* include/debug/safe_iterator.tcc: Define.
(_Safe_iterator<>::_M_invalidate): Adjust, forward to
_M_invalidate_single.
* include/debug/safe_sequence.h (_Safe_sequence<>::_M_invalidate_if,
_M_transfer_iter): Use the mutex, adjust, forward to the *_single
versions of _M_invalidate and _M_attach.
* config/abi/pre/gnu.ver (_Safe_sequence_base::_M_get_mutex,
_Safe_iterator_base::_M_get_mutex, _M_attach_single, _M_detach_single):
Add @GLIBCXX_3.4.9; adjust.
Added:
branches/gcc-4_2-branch/libstdc++-v3/testsuite/18_support/14493.cc
Modified:
branches/gcc-4_2-branch/libstdc++-v3/ChangeLog
branches/gcc-4_2-branch/libstdc++-v3/config/abi/pre/gnu.ver
branches/gcc-4_2-branch/libstdc++-v3/include/debug/safe_base.h
branches/gcc-4_2-branch/libstdc++-v3/include/debug/safe_iterator.h
branches/gcc-4_2-branch/libstdc++-v3/include/debug/safe_iterator.tcc
branches/gcc-4_2-branch/libstdc++-v3/include/debug/safe_sequence.h
branches/gcc-4_2-branch/libstdc++-v3/libsupc++/eh_exception.cc
branches/gcc-4_2-branch/libstdc++-v3/libsupc++/exception
branches/gcc-4_2-branch/libstdc++-v3/libsupc++/new
branches/gcc-4_2-branch/libstdc++-v3/libsupc++/new_handler.cc
branches/gcc-4_2-branch/libstdc++-v3/libsupc++/tinfo.cc
branches/gcc-4_2-branch/libstdc++-v3/libsupc++/typeinfo
branches/gcc-4_2-branch/libstdc++-v3/src/debug.cc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
[not found] <bug-14493-5724@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2007-02-01 13:37 ` paolo at gcc dot gnu dot org
@ 2007-02-01 13:39 ` pcarlini at suse dot de
2007-02-01 15:57 ` paolo at gcc dot gnu dot org
2007-02-01 15:58 ` pcarlini at suse dot de
12 siblings, 0 replies; 37+ messages in thread
From: pcarlini at suse dot de @ 2007-02-01 13:39 UTC (permalink / raw)
To: gcc-bugs
--
pcarlini at suse dot de changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
[not found] <bug-14493-5724@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2007-02-01 2:18 ` lopresti at gmail dot com
@ 2007-02-01 13:37 ` paolo at gcc dot gnu dot org
2007-02-01 13:39 ` pcarlini at suse dot de
` (2 subsequent siblings)
12 siblings, 0 replies; 37+ messages in thread
From: paolo at gcc dot gnu dot org @ 2007-02-01 13:37 UTC (permalink / raw)
To: gcc-bugs
------- Comment #27 from paolo at gcc dot gnu dot org 2007-02-01 13:37 -------
Subject: Bug 14493
Author: paolo
Date: Thu Feb 1 13:36:51 2007
New Revision: 121461
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121461
Log:
2007-02-01 Paolo Carlini <pcarlini@suse.de>
PR libstdc++/14493
* libsupc++/typeinfo (bad_cast::what, bad_typeid::what): Declare.
* libsupc++/tinfo.cc: Define.
* libsupc++/exception (bad_exception::what): Declare.
* libsupc++/eh_exception.cc: Define.
(exception::what): Adjust, don't use typeid.
* libsupc++/new (bad_alloc::what): Declare.
* libsupc++/new_handler.cc: Define.
* config/abi/pre/gnu.ver: Export the new methods @3.4.9; adjust
existing 3.4.10 exports to 3.4.9.
* configure.ac: Adjust to 6.0.9.
* configure: Regenerate.
* testsuite/util/testsuite_abi.cc: Update.
* testsuite/18_support/14493.cc: New.
Added:
trunk/libstdc++-v3/testsuite/18_support/14493.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/abi/pre/gnu.ver
trunk/libstdc++-v3/configure
trunk/libstdc++-v3/configure.ac
trunk/libstdc++-v3/libsupc++/eh_exception.cc
trunk/libstdc++-v3/libsupc++/exception
trunk/libstdc++-v3/libsupc++/new
trunk/libstdc++-v3/libsupc++/new_handler.cc
trunk/libstdc++-v3/libsupc++/tinfo.cc
trunk/libstdc++-v3/libsupc++/typeinfo
trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
[not found] <bug-14493-5724@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2007-01-30 3:53 ` gdr at cs dot tamu dot edu
@ 2007-02-01 2:18 ` lopresti at gmail dot com
2007-02-01 13:37 ` paolo at gcc dot gnu dot org
` (3 subsequent siblings)
12 siblings, 0 replies; 37+ messages in thread
From: lopresti at gmail dot com @ 2007-02-01 2:18 UTC (permalink / raw)
To: gcc-bugs
------- Comment #26 from lopresti at gmail dot com 2007-02-01 02:17 -------
I found this PR because I tried calling what() on a bad_alloc, was surprised by
what I got, and did a search. This is my perspective as a random end user;
make of it what you will.
I think "std::bad_alloc" is an improvement. But I was actually expecting
what() to provide something human readable and very specific, like "out of
memory" or "heap corrupted". In my case, I already know the exception is a
std::bad_alloc; I could generate that particular constant string myself...
I find it remarkable that this PR is almost two years old.
--
lopresti at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |lopresti at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
[not found] <bug-14493-5724@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2007-01-30 2:21 ` pcarlini at suse dot de
@ 2007-01-30 3:53 ` gdr at cs dot tamu dot edu
2007-02-01 2:18 ` lopresti at gmail dot com
` (4 subsequent siblings)
12 siblings, 0 replies; 37+ messages in thread
From: gdr at cs dot tamu dot edu @ 2007-01-30 3:53 UTC (permalink / raw)
To: gcc-bugs
------- Comment #25 from gdr at cs dot tamu dot edu 2007-01-30 03:53 -------
Subject: Re: std::bad_alloc::what() does not explain what happened
"pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes:
| > However, the use of typeid is very convenient in the sense that we
| > have to defined what() only once. Now, if we change that definition
| > in std::exception, it means that we should revisit all other exception
| > classes, such as std::runtime_error, etc.
|
| I see, but I don't think we have to do much, because the other exception
| classes, provided in <stdexcept>, per the standard requirements are already
| overriding what() to return _M_msg.c_str(). Thus, I'm coming to the
conclusion
| that we should consistently change std::exception too and be done with it.
You're right. I agree with your analysis.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
[not found] <bug-14493-5724@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2007-01-30 2:11 ` gdr at cs dot tamu dot edu
@ 2007-01-30 2:21 ` pcarlini at suse dot de
2007-01-30 3:53 ` gdr at cs dot tamu dot edu
` (5 subsequent siblings)
12 siblings, 0 replies; 37+ messages in thread
From: pcarlini at suse dot de @ 2007-01-30 2:21 UTC (permalink / raw)
To: gcc-bugs
------- Comment #24 from pcarlini at suse dot de 2007-01-30 02:21 -------
(In reply to comment #23)
> From consistency point of view I would say that the change should also
> be done for std::exception.
Right.
> However, the use of typeid is very convenient in the sense that we
> have to defined what() only once. Now, if we change that definition
> in std::exception, it means that we should revisit all other exception
> classes, such as std::runtime_error, etc.
I see, but I don't think we have to do much, because the other exception
classes, provided in <stdexcept>, per the standard requirements are already
overriding what() to return _M_msg.c_str(). Thus, I'm coming to the conclusion
that we should consistently change std::exception too and be done with it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
[not found] <bug-14493-5724@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2007-01-30 1:42 ` pcarlini at suse dot de
@ 2007-01-30 2:11 ` gdr at cs dot tamu dot edu
2007-01-30 2:21 ` pcarlini at suse dot de
` (6 subsequent siblings)
12 siblings, 0 replies; 37+ messages in thread
From: gdr at cs dot tamu dot edu @ 2007-01-30 2:11 UTC (permalink / raw)
To: gcc-bugs
------- Comment #23 from gdr at cs dot tamu dot edu 2007-01-30 02:11 -------
Subject: Re: std::bad_alloc::what() does not explain what happened
"pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes:
| ------- Comment #22 from pcarlini at suse dot de 2007-01-30 01:42 -------
| (In reply to comment #21)
| > I suspect Andrew Pinski's point might be that what() could return a
| > string that represents the name of the most derived type of the
| > exception. But, nothing so far forces to do that. A reasonable
| > definition is to what Paolo suggest, with clear documentation (that
| > mentions this).
|
| Agreed. Gaby, do you have any strong opinion about std::exception
| itself? In my current patch draft I'm leaving it alone, but in
| principle we could change also its what() to return "std::exception"
| instead of typeid(*this).name().
>From consistency point of view I would say that the change should also
be done for std::exception.
However, the use of typeid is very convenient in the sense that we
have to defined what() only once. Now, if we change that definition
in std::exception, it means that we should revisit all other exception
classes, such as std::runtime_error, etc.
I have no strong opinion. Probably just leave it as is, and document
the choices we face so that people see the rationale behind the
implementations.
Thanks,
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
[not found] <bug-14493-5724@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2007-01-30 1:30 ` gdr at cs dot tamu dot edu
@ 2007-01-30 1:42 ` pcarlini at suse dot de
2007-01-30 2:11 ` gdr at cs dot tamu dot edu
` (7 subsequent siblings)
12 siblings, 0 replies; 37+ messages in thread
From: pcarlini at suse dot de @ 2007-01-30 1:42 UTC (permalink / raw)
To: gcc-bugs
------- Comment #22 from pcarlini at suse dot de 2007-01-30 01:42 -------
(In reply to comment #21)
> I suspect Andrew Pinski's point might be that what() could return a
> string that represents the name of the most derived type of the
> exception. But, nothing so far forces to do that. A reasonable
> definition is to what Paolo suggest, with clear documentation (that
> mentions this).
Agreed. Gaby, do you have any strong opinion about std::exception itself? In my
current patch draft I'm leaving it alone, but in principle we could change also
its what() to return "std::exception" instead of typeid(*this).name(). In other
terms, I'm not sure whether your Comment #13 contrary to the mangled typeid
applies also to the base std::exception...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
[not found] <bug-14493-5724@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2007-01-30 0:58 ` pcarlini at suse dot de
@ 2007-01-30 1:30 ` gdr at cs dot tamu dot edu
2007-01-30 1:42 ` pcarlini at suse dot de
` (8 subsequent siblings)
12 siblings, 0 replies; 37+ messages in thread
From: gdr at cs dot tamu dot edu @ 2007-01-30 1:30 UTC (permalink / raw)
To: gcc-bugs
------- Comment #21 from gdr at cs dot tamu dot edu 2007-01-30 01:30 -------
Subject: Re: std::bad_alloc::what() does not explain what happened
"pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes:
| What do you mean by "incorrect"?!? If you subclass, either you
| provide your own what(), or you get the what() provided by the base
| class, which is implementation defined and, very reasonably,
| "std::bad_cast" for class bad_cast, and so on...
Paolo is technically right: what() is a virtual member function; so
one should not derive from those classes and except that what()
returned something they did not define or we did not promise.
I suspect Andrew Pinski's point might be that what() could return a
string that represents the name of the most derived type of the
exception. But, nothing so far forces to do that. A reasonable
definition is to what Paolo suggest, with clear documentation (that
mentions this).
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
[not found] <bug-14493-5724@http.gcc.gnu.org/bugzilla/>
2007-01-30 0:34 ` pcarlini at suse dot de
2007-01-30 0:54 ` pinskia at gcc dot gnu dot org
@ 2007-01-30 0:58 ` pcarlini at suse dot de
2007-01-30 1:30 ` gdr at cs dot tamu dot edu
` (9 subsequent siblings)
12 siblings, 0 replies; 37+ messages in thread
From: pcarlini at suse dot de @ 2007-01-30 0:58 UTC (permalink / raw)
To: gcc-bugs
------- Comment #20 from pcarlini at suse dot de 2007-01-30 00:58 -------
(In reply to comment #19)
> I don't think that is the correct solution as if you subclass these functions,
> you get the incorrect result.
What do you mean by "incorrect"?!? If you subclass, either you provide your own
what(), or you get the what() provided by the base class, which is
implementation defined and, very reasonably, "std::bad_cast" for class
bad_cast, and so on...
--
pcarlini at suse dot de changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gdr at integrable-solutions
| |dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
[not found] <bug-14493-5724@http.gcc.gnu.org/bugzilla/>
2007-01-30 0:34 ` pcarlini at suse dot de
@ 2007-01-30 0:54 ` pinskia at gcc dot gnu dot org
2007-01-30 0:58 ` pcarlini at suse dot de
` (10 subsequent siblings)
12 siblings, 0 replies; 37+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2007-01-30 0:54 UTC (permalink / raw)
To: gcc-bugs
------- Comment #19 from pinskia at gcc dot gnu dot org 2007-01-30 00:54 -------
(In reply to comment #18)
> Implementing the really trivial solution of providing what() members returning
> "std::bad_alloc", "std::bad_cast", "std::bad_typeid", and "std::bad_exception".
I don't think that is the correct solution as if you subclass these functions,
you get the incorrect result.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
[not found] <bug-14493-5724@http.gcc.gnu.org/bugzilla/>
@ 2007-01-30 0:34 ` pcarlini at suse dot de
2007-01-30 0:54 ` pinskia at gcc dot gnu dot org
` (11 subsequent siblings)
12 siblings, 0 replies; 37+ messages in thread
From: pcarlini at suse dot de @ 2007-01-30 0:34 UTC (permalink / raw)
To: gcc-bugs
------- Comment #18 from pcarlini at suse dot de 2007-01-30 00:34 -------
Implementing the really trivial solution of providing what() members returning
"std::bad_alloc", "std::bad_cast", "std::bad_typeid", and "std::bad_exception".
--
pcarlini at suse dot de changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2023-04-27 23:04 UTC | newest]
Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-03-08 22:10 [Bug libstdc++/14493] New: new: No std::bad_alloc::what() const debian-gcc at lists dot debian dot org
2004-03-08 22:37 ` [Bug libstdc++/14493] " pinskia at gcc dot gnu dot org
2004-03-08 23:15 ` [Bug libstdc++/14493] " bangerth at dealii dot org
2004-03-09 4:14 ` pme at gcc dot gnu dot org
2004-03-09 4:14 ` phil at jaj dot com
2004-03-09 4:45 ` zack at gcc dot gnu dot org
2004-03-09 5:19 ` doko at cs dot tu-berlin dot de
2004-03-09 18:32 ` jtv at xs4all dot nl
2004-03-09 19:32 ` phil at jaj dot com
2004-03-09 19:48 ` pme at gcc dot gnu dot org
2004-03-09 20:14 ` Zack Weinberg
2004-03-09 20:14 ` zack at codesourcery dot com
2004-03-10 1:12 ` giovannibajo at libero dot it
2004-03-11 7:35 ` pme at gcc dot gnu dot org
2004-03-11 10:05 ` gdr at integrable-solutions dot net
2004-03-11 15:51 ` bangerth at dealii dot org
2004-03-11 15:52 ` bangerth at dealii dot org
2004-04-27 13:54 ` [Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened pinskia at gcc dot gnu dot org
2004-08-05 14:37 ` pcarlini at suse dot de
2004-08-05 15:01 ` pcarlini at suse dot de
[not found] <bug-14493-5724@http.gcc.gnu.org/bugzilla/>
2007-01-30 0:34 ` pcarlini at suse dot de
2007-01-30 0:54 ` pinskia at gcc dot gnu dot org
2007-01-30 0:58 ` pcarlini at suse dot de
2007-01-30 1:30 ` gdr at cs dot tamu dot edu
2007-01-30 1:42 ` pcarlini at suse dot de
2007-01-30 2:11 ` gdr at cs dot tamu dot edu
2007-01-30 2:21 ` pcarlini at suse dot de
2007-01-30 3:53 ` gdr at cs dot tamu dot edu
2007-02-01 2:18 ` lopresti at gmail dot com
2007-02-01 13:37 ` paolo at gcc dot gnu dot org
2007-02-01 13:39 ` pcarlini at suse dot de
2007-02-01 15:57 ` paolo at gcc dot gnu dot org
2007-02-01 15:58 ` pcarlini at suse dot de
[not found] <bug-14493-4@http.gcc.gnu.org/bugzilla/>
2023-04-04 11:17 ` cvs-commit at gcc dot gnu.org
2023-04-20 13:57 ` cvs-commit at gcc dot gnu.org
2023-04-27 22:01 ` cvs-commit at gcc dot gnu.org
2023-04-27 23:04 ` cvs-commit at gcc dot gnu.org
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).