* [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; 20+ 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] 20+ 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 ` [Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened 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; 20+ 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] 20+ 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 ` [Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened 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; 20+ 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] 20+ 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; 20+ 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] 20+ 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; 20+ 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] 20+ 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; 20+ 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] 20+ 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; 20+ 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] 20+ 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; 20+ 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] 20+ 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; 20+ 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] 20+ 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; 20+ 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] 20+ 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; 20+ 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] 20+ 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; 20+ 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] 20+ 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; 20+ 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] 20+ messages in thread