On Feb 16, 2006, at 1:18 PM, Joern RENNECKE wrote:
Andrew Pinski wrote:
GCC before 4.0.0 was incorrect at not rejecting this code.
See PR 19333.
Use -pedantic with 3.2.3 and you will get a warning.
Yes, I do, but it is also questionable if this warning is required or
even useful.
Also see:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00948.html
The issue there is completely different. The array has definetly no
completed type.
In the testcase I have given - which is pruned down from the pthread.h
header file on
a linux installation - after applying adjustment, you get:
extern void f (struct tag *a);
which is fine. So this is only about the technicality if the
adjustment is actually
defined in this case. It appears to me that the intent of the
standard was that this
should be defined, while the letter of it is not even self-consistet.
See also:
http://gcc.gnu.org/ml/gcc/2005-02/msg00011.html
Even more important:
http://gcc.gnu.org/ml/gcc/2005-02/msg00026.html
Which is the answer you are looking for:
But the constraint in C99 is on array declarators, "The element type
shall
not be an incomplete or function type.". This applies to the syntax
whenever it describes an array type even that array type then gets
adjusted to a pointer type. In C90, without the constraint, there was
undefined behavior for an array of incomplete type, even in parameter
context: DR#047 example 3 is almost exactly this case
/* 3 */ struct S *g(struct S a[]) {return a; }
and was said to involve undefined behavior. "However, there is nothing
to
suggest that a not-strictly-conforming array type can magically be
transformed into a strictly conforming pointer parameter via this rule."
-- Pinski
