[Bug c++/31988] New: new operator should not permit default first parameter

[Bug c++/31988] New: new operator should not permit default first parameter

[andrew dot stubbs at st dot com]

The following C++ program should not compile:

#include <new>
class C
{
public:
  void * operator new (size_t = 32); // invalid
};

The C++ standard, clause 3.7.3.1, paragraph 1, says that the first parameter to
new should not have a default argument. GCC gives no error and no warning.


-- 
           Summary: new operator should not permit default first parameter
           Product: gcc
           Version: 4.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: andrew dot stubbs at st dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31988

[Bug c++/31988] new operator should not permit default first parameter

[pcarlini at suse dot de]

------- Comment #1 from pcarlini at suse dot de  2007-09-22 00:04 -------
On it.


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-09-22 00:04:31
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31988

[Bug c++/31988] new operator should not permit default first parameter

[pcarlini at suse dot de]

------- Comment #2 from pcarlini at suse dot de  2007-09-28 15:43 -------
Patch at:

  http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01711.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31988

[Bug c++/31988] new operator should not permit default first parameter

[andrew dot stubbs at st dot com]

------- Comment #3 from andrew dot stubbs at st dot com  2007-09-28 16:00 -------
I'm not a GCC expert, but that patch looks like it will silently change the
behaviour of the compiler when -pedantic is not given.

I would suggest that the first parameter should either be a regular,
non-pedantic warning, or else should honour the default as requested by the
user (as a language extension).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31988

[Bug c++/31988] new operator should not permit default first parameter

[pcarlini at suse dot de]

------- Comment #4 from pcarlini at suse dot de  2007-09-28 16:11 -------
(In reply to comment #3)
> I'm not a GCC expert, but that patch looks like it will silently change the
> behaviour of the compiler when -pedantic is not given.

When -pedantic is not given (the default) a pedwarn is an hard error. A pedwarn
becomes a warning when -permissive is passes (and the code is thus accepted as
an extension, which I would find useful for legacy code). But I have no strong
opinion, in general.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31988

[Bug c++/31988] new operator should not permit default first parameter

[pcarlini at suse dot de]

------- Comment #5 from pcarlini at suse dot de  2007-09-28 16:20 -------
About the behavior when -fpermissive is passed - essentially, removing the
default and going ahead, I followed the other pedwarn in the same function -
but the alternate behavior, not doing anything special and just going ahead
after the warning and accepting the code would be also ok with me.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31988

[Bug c++/31988] new operator should not permit default first parameter

[andrew dot stubbs at st dot com]

------- Comment #6 from andrew dot stubbs at st dot com  2007-09-28 16:28 -------
(In reply to comment #4)
> When -pedantic is not given (the default) a pedwarn is an hard error. A pedwarn
> becomes a warning when -permissive is passes (and the code is thus accepted as
> an extension, which I would find useful for legacy code). But I have no strong
> opinion, in general.

Ah, my mistake. I have the sense of pedwarn backwards. For some reason, I
thought it meant give a warning in pedantic mode only. Well, it is Friday. :)

Of course, with the true meaning of pedwarn, this patch still provides no way
to get back to the current state, even with -fpermissive. However, since the
current behaviour is wrong, and I for one have no interest in such an
extension, I'll not complain.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31988

[Bug c++/31988] new operator should not permit default first parameter

[paolo at gcc dot gnu dot org]

------- Comment #7 from paolo at gcc dot gnu dot org  2007-10-26 18:32 -------
Subject: Bug 31988

Author: paolo
Date: Fri Oct 26 18:32:41 2007
New Revision: 129657

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129657
Log:
cp/
2007-10-26  Paolo Carlini  <pcarlini@suse.de>

        PR c++/31988
        * decl2.c (coerce_new_type): Do not allow a default argument for
        the first parameter.

testsuite/
2007-10-26  Paolo Carlini  <pcarlini@suse.de>

        PR c++/31988
        * g++.dg/init/new25.C: New.

Added:
    trunk/gcc/testsuite/g++.dg/init/new25.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/decl2.c
    trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31988

[Bug c++/31988] new operator should not permit default first parameter

[pcarlini at suse dot de]

------- Comment #8 from pcarlini at suse dot de  2007-10-26 18:34 -------
Fixed for 4.3.0.


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31988