This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/11228] [3.3/3.4 regression] ICE on new-expression using array operator new and default-initialization
- From: "austern at apple dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 18 Jun 2003 04:34:19 -0000
- Subject: [Bug c++/11228] [3.3/3.4 regression] ICE on new-expression using array operator new and default-initialization
- References: <20030617231527.11228.austern@apple.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11228
austern at apple dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned@gcc.gnu.org |austern@apple.com
------- Additional Comments From austern at apple dot com 2003-06-18 04:34 -------
Here's my understanding of 5.3.4/p14: an expression like "new T[n](a,b,c)" is illegal, but an
expression like "new T[n]()" is legal. (The former is the gcc extension that Wolfgang was
referring to.) The point is that 5.3.4/p14 explicitly distinguishes between a new-initializer of the
form "()" and one that's non-empty. It prohibits the latter for array new expressions, but says
nothing about the former. And just to make life a little more fun, "new T[n]" and "new T[n]()" don't
always mean quite the same thing.
I've confirmed my interpretation with the C++ standards committee.