[Bug libstdc++/14493] New: new: No std::bad_alloc::what() const

[Bug libstdc++/14493] New: new: No std::bad_alloc::what() const

[debian-gcc at lists dot debian dot org]

[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

[Bug libstdc++/14493] new: No std::bad_alloc::what() const

[pinskia at gcc dot gnu dot org]

------- 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

[Bug libstdc++/14493] No std::bad_alloc::what() const

[bangerth at dealii dot org]

------- 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

[Bug libstdc++/14493] No std::bad_alloc::what() const

[pme at gcc dot gnu dot org]

------- 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

[Bug libstdc++/14493] No std::bad_alloc::what() const

[phil at jaj dot com]

------- 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

[Bug libstdc++/14493] No std::bad_alloc::what() const

[zack at gcc dot gnu dot org]

------- 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

[Bug libstdc++/14493] No std::bad_alloc::what() const

[doko at cs dot tu-berlin dot de]

------- 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

[Bug libstdc++/14493] No std::bad_alloc::what() const

[jtv at xs4all dot nl]

------- 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

[Bug libstdc++/14493] No std::bad_alloc::what() const

[phil at jaj dot com]

------- 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

[Bug libstdc++/14493] No std::bad_alloc::what() const

[pme at gcc dot gnu dot org]

------- 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

Re: [Bug libstdc++/14493] No std::bad_alloc::what() const

[Zack Weinberg]

"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

[Bug libstdc++/14493] No std::bad_alloc::what() const

[zack at codesourcery dot com]

------- 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

[Bug libstdc++/14493] No std::bad_alloc::what() const

[giovannibajo at libero dot it]

------- 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

[Bug libstdc++/14493] No std::bad_alloc::what() const

[pme at gcc dot gnu dot org]

------- 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

[Bug libstdc++/14493] No std::bad_alloc::what() const

[gdr at integrable-solutions dot net]

------- 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

[Bug libstdc++/14493] No std::bad_alloc::what() const

[bangerth at dealii dot org]

------- 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

[Bug libstdc++/14493] No std::bad_alloc::what() const

[bangerth at dealii dot org]

------- 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

[Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened

[pinskia at gcc dot gnu dot org]

-- 
           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

[Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened

[pcarlini at suse dot de]

------- 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

[Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened

[pcarlini at suse dot de]

------- 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