This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/13963] New: gcc rejects array of unknown bounds as parameter of function template specialization
- From: "austern at apple dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 1 Feb 2004 19:42:09 -0000
- Subject: [Bug c++/13963] New: gcc rejects array of unknown bounds as parameter of function template specialization
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
Every version of g++ that I've tested (2.95, 3.1, 3.3, mainline) rejects the following code:
template<typename X> void h(X x) { }
void foo()
{
int A[9];
h<int[]>(A);
}
EDG accepts this code. I believe EDG is correct. When instantiating h, int[] should be treated as a
synonym for int*.
My analysis:
- First, just to clear away an irrelevancy: there's a standard array-to-pointer conversion, but it
doesn't matter. We're talking about the legality of a declaration.
- Second, again mostly as a sanity check: void f(int a[]) { } is legal C++, just like it's legal C. But
the reason it's legal matters: clause 8.3.5, paragraph 3, says: The type of each parameter is
determined from its own decl-specifier-seq and declarator. After determining the type of each
parameter, any parameter of type ?array of T? or ?function returningT? is adjusted to be ?pointer
toT? or ?pointer to function returningT,? respectively.
- Finally, the only remaining question is: when instantiating a function template whose template
arguments are explicitly provided, is the compiler supposed to perform the same parameter
adjustments as in an ordinary function declaration? The answer is yes. 14.8.2, paragraph 3, says:
After this substitution is performed, the function parameter type adjustments described in 8.3.5
are performed.
--
Summary: gcc rejects array of unknown bounds as parameter of
function template specialization
Product: gcc
Version: 3.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: austern at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13963