Debian Bug report logs - #44356
bug in new.h

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Colin McCormack <colin@field.medicine.adelaide.edu.au>

To: submit@bugs.debian.org

Subject: bug in new.h

Date: Fri, 03 Sep 1999 08:42:30 +1000

Package: g++
Version: 2.95.1-1

/usr/lib/gcc-lib/i386-linux/2.95.1/include/new lines 37.. are:

// default placement versions of operator new
inline void *operator new(size_t, void *place) throw() { return place; }
inline void *operator new[](size_t, void *place) throw() { return place; }

The use of inline definition here precludes me from defining my own new
operators.

I consider this a bug.

I suggest the { return place; } bodies be removed, and the definition 
be moved somewhere less intrusive.

Colin.

Message #10 received at 44356@bugs.debian.org (full text, mbox, reply):

From: Daniel Jacobowitz <drow@false.org>

To: Matthias Klose <doko@cs.tu-berlin.de>

Cc: Colin McCormack <colin@field.medicine.adelaide.edu.au>, 44356@bugs.debian.org

Subject: Re: patch needed to build gcc on ppc

Date: Tue, 7 Sep 1999 13:51:44 -0400

On Tue, Sep 07, 1999 at 06:09:24PM +0200, Matthias Klose wrote:
> Daniel Jacobowitz writes:
>  > On Mon, Sep 06, 1999 at 05:27:32PM -0400, Daniel Jacobowitz wrote:
>  > > Anyway, this version still can't build apt; I have a workaround which
>  > > I'm testing now.
>  > 
>  > Yep, fixed it.  This patch is a bit of a hack; it's been fixed in the
>  > mainline much better.  Should be completely safe though.
> 
> the patch is not ppc specific, isn't it?

No, it's not PPC specific.  It only happens on PPC, but that it happens
at all is a wierd fluke of bad luck.

> 
> May I ask you to look at the report
> 
> 	http://www.debian.org/Bugs/db/44/44356.html 
> 
> Is there a way to fix the libstdc++-out-of-mem.dpatch report _and_ to
> fix 44356?

I don't see how #44356 is a bug.  It prevents him from defining his own
two-argument new function in the default namespace; he can still define
one in any class he chooses.  If the function bodies were off in a
library somewhere he would have to override them in order to redefine
new, which is not a legal course of action in C++, as far as I know.


> 
> Thanks, Matthias
> 


Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

Message #15 received at 44356@bugs.debian.org (full text, mbox, reply):

From: Matthias Klose <doko@cs.tu-berlin.de>

To: Daniel Jacobowitz <drow@false.org>, 44356@bugs.debian.org

Subject: Bug#44356: patch needed to build gcc on ppc

Date: Tue, 7 Sep 1999 20:13:51 +0200 (MET DST)

Daniel Jacobowitz writes:
 > On Tue, Sep 07, 1999 at 06:09:24PM +0200, Matthias Klose wrote:
 > > Daniel Jacobowitz writes:
 > >  > On Mon, Sep 06, 1999 at 05:27:32PM -0400, Daniel Jacobowitz wrote:
 > >  > > Anyway, this version still can't build apt; I have a workaround which
 > >  > > I'm testing now.
 > >  > 
 > >  > Yep, fixed it.  This patch is a bit of a hack; it's been fixed in the
 > >  > mainline much better.  Should be completely safe though.
 > > 
 > > the patch is not ppc specific, isn't it?
 > 
 > No, it's not PPC specific.  It only happens on PPC, but that it happens
 > at all is a wierd fluke of bad luck.

ok, then I change the prefix frpm ppc to g++.

 > > May I ask you to look at the report
 > > 
 > > 	http://www.debian.org/Bugs/db/44/44356.html 
 > > 
 > > Is there a way to fix the libstdc++-out-of-mem.dpatch report _and_ to
 > > fix 44356?
 > 
 > I don't see how #44356 is a bug.  It prevents him from defining his own
 > two-argument new function in the default namespace; he can still define
 > one in any class he chooses.  If the function bodies were off in a
 > library somewhere he would have to override them in order to redefine
 > new, which is not a legal course of action in C++, as far as I know.

sorry, wrong bug number ... 44446

Message #20 received at 44356-done@bugs.debian.org (full text, mbox, reply):

From: Matthias Klose <doko@cs.tu-berlin.de>

To: 44356-done@bugs.debian.org

Cc: colin@field.medicine.adelaide.edu.au

Subject: debian bug report #44356 not considered a bug

Date: Thu, 4 Nov 1999 21:06:08 +0100 (MET)

Daniel Jacobowitz writes:
 > I don't see how #44356 is a bug.  It prevents him from defining his own
 > two-argument new function in the default namespace; he can still define
 > one in any class he chooses.  If the function bodies were off in a
 > library somewhere he would have to override them in order to redefine
 > new, which is not a legal course of action in C++, as far as I know.

Message #25 received at 44356@bugs.debian.org (full text, mbox, reply):

From: Matthias Klose <doko@cs.tu-berlin.de>

To: control@bugs.debian.org

Cc: Colin McCormack <colin@field.medicine.adelaide.edu.au>, 44356@bugs.debian.org, dan@debian.org

Subject: Re: debian bug report #44356 not considered a bug

Date: Fri, 5 Nov 1999 11:13:28 +0100 (MET)

reopen 44356
thanks

please don't open new bugs, when adding information to already
reported ones. Somebody wants to forward this to gcc-bugs@gcc.gnu.org?

Colin McCormack writes:
 > Hi,
 > 
 > Daniel Jacobowitz is mistaken, it prevents me from overriding an operator.
 > 
 > As far as I'm aware, overriding an operator is perfectly legal in C++.
 > 
 > I look at the draft C++ standard, here:
 > 	http://www.cygnus.com:80/misc/wp/draft/lib-support.html#lib.new.delete
 > 
 > And it says (of dyadic operator new):
 > 	a  C++  program  may  define a function with this function signature
 > 	that displaces the default  version  defined  by  the  C++  Standard
 > 	library.
 > 
 > So this library doesn't conform to the standard.  Not a bug?
 > 
 > Colin.
 > 
 > > Daniel Jacobowitz writes:
 > >  > I don't see how #44356 is a bug.  It prevents him from defining his own
 > >  > two-argument new function in the default namespace; he can still define
 > >  > one in any class he chooses.  If the function bodies were off in a
 > >  > library somewhere he would have to override them in order to redefine
 > >  > new, which is not a legal course of action in C++, as far as I know.
 > 

Message #32 received at 44356@bugs.debian.org (full text, mbox, reply):

From: Matthias Klose <doko@cs.tu-berlin.de>

To: gcc-bugs@gcc.gnu.org

Cc: 44356@bugs.debian.org, Colin McCormack <colin@field.medicine.adelaide.edu.au>, dan@debian.org

Subject: bug in new.h?

Date: Wed, 10 Nov 1999 19:43:30 +0100 (MET)

[ This feature or bug was reported to the Debian bug tracking system;
  please CC 44356@bugs.debian.org for replys.
  See http://www.debian.org/Bugs/db/44/44356.html for the complete report]

The submitter of the bug reported:

> /usr/lib/gcc-lib/i386-linux/2.95.1/include/new lines 37.. are:
> 
> // default placement versions of operator new
> inline void *operator new(size_t, void *place) throw() { return place; }
> inline void *operator new[](size_t, void *place) throw() { return place; }
> 
> The use of inline definition here precludes me from defining my own new
> operators.
> 
> I consider this a bug.
> 
> I suggest the { return place; } bodies be removed, and the definition 
> be moved somewhere less intrusive.

Another developer responded:

> I don't see how #44356 is a bug.  It prevents him from defining his
> own two-argument new function in the default namespace; he can still
> define one in any class he chooses.  If the function bodies were off
> in a library somewhere he would have to override them in order to
> redefine new, which is not a legal course of action in C++, as far
> as I know.

and the response of the bug submitter:

 > Daniel Jacobowitz is mistaken, it prevents me from overriding an operator.
 > 
 > As far as I'm aware, overriding an operator is perfectly legal in C++.
 > 
 > I look at the draft C++ standard, here:
 >      http://www.cygnus.com:80/misc/wp/draft/lib-support.html#lib.new.delete
 > 
 > And it says (of dyadic operator new):
 >      a  C++  program  may  define a function with this function signature
 >      that displaces the default  version  defined  by  the  C++  Standard
 >      library.
 > 
 > So this library doesn't conform to the standard.  Not a bug?

Message #39 received at 44356@bugs.debian.org (full text, mbox, reply):

From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>

To: doko@cs.tu-berlin.de

Cc: gcc-bugs@gcc.gnu.org, 44356@bugs.debian.org, colin@field.medicine.adelaide.edu.au, dan@debian.org

Subject: Re: bug in new.h?

Date: Sun, 21 Nov 1999 18:46:26 +0100

>  > I look at the draft C++ standard, here:
>  >      http://www.cygnus.com:80/misc/wp/draft/lib-support.html#lib.new.delete
>  > 
>  > And it says (of dyadic operator new):
>  >      a  C++  program  may  define a function with this function signature
>  >      that displaces the default  version  defined  by  the  C++  Standard
>  >      library.
>  > 
>  > So this library doesn't conform to the standard.  Not a bug?

Not a bug, the library conforms to the standard. Looking at ISO/IEC
14882:1998(E) (which is essentially the same as the draft cited above
in this aspect), I see 18.4.1.3, [lib.new.delete.placement]/1

# These functions are reserved, a C++ program may not define functions
# that displace the versions in the Standard C++ library (17.4.3).
#
#     void* operator new(std::size_t size, void* ptr) throw();

I don't know which dyadic variant of operator new you were originally
looking at; perhaps the 'nothrow' version? This is different from the
placement version.

Regards,
Martin

Message #44 received at 44356-done@bugs.debian.org (full text, mbox, reply):

From: Daniel Jacobowitz <dan@debian.org>

To: 44356-done@bugs.debian.org

Subject: [martin@mira.isdn.cs.tu-berlin.de: Re: bug in new.h?]

Date: Sun, 21 Nov 1999 12:56:16 -0500

And on this note I'm closing the bug.


----- Forwarded message from "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> -----

Date: Sun, 21 Nov 1999 18:46:26 +0100
From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
To: doko@cs.tu-berlin.de
CC: gcc-bugs@gcc.gnu.org, 44356@bugs.debian.org,
        colin@field.medicine.adelaide.edu.au, dan@debian.org
Subject: Re: bug in new.h?

>  > I look at the draft C++ standard, here:
>  >      http://www.cygnus.com:80/misc/wp/draft/lib-support.html#lib.new.delete
>  > 
>  > And it says (of dyadic operator new):
>  >      a  C++  program  may  define a function with this function signature
>  >      that displaces the default  version  defined  by  the  C++  Standard
>  >      library.
>  > 
>  > So this library doesn't conform to the standard.  Not a bug?

Not a bug, the library conforms to the standard. Looking at ISO/IEC
14882:1998(E) (which is essentially the same as the draft cited above
in this aspect), I see 18.4.1.3, [lib.new.delete.placement]/1

# These functions are reserved, a C++ program may not define functions
# that displace the versions in the Standard C++ library (17.4.3).
#
#     void* operator new(std::size_t size, void* ptr) throw();

I don't know which dyadic variant of operator new you were originally
looking at; perhaps the 'nothrow' version? This is different from the
placement version.

Regards,
Martin


----- End forwarded message -----


Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

Send a report that this bug log contains spam.