an error about C struct array in formal parameter

Question

I have got the following code:

struct student_info;
void paiming1(struct student_info student[]); 
struct student_info  
{
    int num; 
    char name[6]; 
};

The IDE gives an error

error: array type has incomplete element type ‘struct student_info’
 void paiming1(struct student_info student[]);

But if I use void paiming1(struct student_info *student); it works OK. Why is that? I am using GCC.

Answer 1

С language unconditionally requires array element type in all array declarations to be complete. Period.

6.7.6.2 Array declarators
Constraints
1 [...] The element type shall not be an incomplete or function type. [...]

No exception is made for array declarations used in function parameter lists. This is different from C++ - the latter drops this completeness requirement for function parameter lists

struct S;
void foo(struct S[]); // OK in C++, invalid in C

Considering that in parameter list declaration type T [] is later adjusted to type T * anyway, this requirement might appear to be excessive. (And this is why C++ relaxed it.) Nevertheless, this restriction is present in C language. This is just one of the quirks of C language.

As you already know, you can explicitly switch to the equivalent

void paiming1(struct student_info *student); 

form to work around the issue.

Answer 2

Careful reading of the standard makes it clear that in C99 and C11 the declaration is supposed to be a constraint violation. C11 6.7.2.6 Array declarations p1

1. In addition to optional type qualifiers and the keyword static, the [ and ] may delimit an expression or *. If they delimit an expression (which specifies the size of an array), the expression shall have an integer type. If the expression is a constant expression, it shall have a value greater than zero. The element type shall not be an incomplete or function type. The optional type qualifiers and the keyword static shall appear only in a declaration of a function parameter with an array type, and then only in the outermost array type derivation.

Since this contains references to the * that is valid only in function declarations that are not definitions, and nowhere else, the constraints as whole needs to be taken as applying to parameters.

---

For C90 the case is more complicated. This is actually discussed in C90 Defect Report 47 from 10 December, 1992.

2 of the 6 declarations given there are

/* 1. */ struct S;
/* 3. */ struct S *g(struct S a[]) { return a; }

and the defect report asks if these are strictly-conforming. It must be noted that unlike the question, these are prototypes that are part of definition rather than just declaration.

Nevertheless, the standard committee responds by saying that

The struct S is an incomplete type (subclause 6.5.2.3, page 62, lines 25-28). Also, an array of unknown size is an incomplete type (subclause 6.5.4.2, page 67, lines 9-10). Therefore, arrays of either of the above are not strictly conforming (subclause 6.1.2.5, page 23, lines 23-24). This makes declarations 3, 4, and 6 not strictly conforming. (But an implementation could get it right.)

As an aside, array parameters are adjusted to pointer type (subclause 6.7.1, page 82, lines 23-24). 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.

The types in question can be interpreted two different ways. (Array to pointer conversion can happen as soon as possible or as late as possible.) Hence a program that uses such a form has undefined behavior.

(emphasis mine)

Since this has not been clarified in writing since 1992, we must agree that the behaviour is undefined and therefore the C standard imposes no requirements, and a compiler that successfully compiles this this can still conform to C90.

The committee also states that there is no constraint violation in C90, therefore a C90 conforming compiler need not output any diagnostics.

I've edited the answer; I previously claimed that this would apply to C99 and C11 alike, but the text was changed in C99 as above, therefore this is a constraint violation in C99, C11.