[Bug c++/21603] New: C++ front-end accepts "new" with VLAs

[Bug c++/21603] New: C++ front-end accepts "new" with VLAs

[mmitchel at gcc dot gnu dot org]

All three lines marked with comments in:

void f(int n) {
  typedef int T[n][n];
  new int[n][n]; // #1                                                          
  new (int[n][n]); // #2                                                        
  new T; // #3                                                                  
}

are invalid, but only the first receives an error without -pedantic.

That's an inconsistency; either we should allow all, or none, of the
declarations.  Which should it be?

Steve Adamczyk has indicated that he feels that permitting dynamic allocation of
VLAs is a mistake, in that, for example, you can't easily use the pointer
outside the scope of the containing function, unless you somehow also pass/save
the bounds.

-- 
           Summary: C++ front-end accepts "new" with VLAs
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mmitchel at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org,jason at redhat dot
                    com,nathan at codesourcery dot com


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

[Bug c++/21603] C++ front-end accepts "new" with VLAs

[jason at redhat dot com]

------- Additional Comments From jason at redhat dot com  2005-05-16 20:28 -------
Subject: Re:  New: C++ front-end accepts "new" with VLAs

On 16 May 2005 02:16:51 -0000, "mmitchel at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> wrote:

> Steve Adamczyk has indicated that he feels that permitting dynamic allocation of
> VLAs is a mistake, in that, for example, you can't easily use the pointer
> outside the scope of the containing function, unless you somehow also pass/save
> the bounds.

Makes sense to me.

Jason


-- 


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