🚀 go-pugleaf

In article <1993Jan28.073947.6951@g2syd.genasys.com.au> andrewc@g2syd.genasys.com.au (Andrew Congdon) writes:
>I have a function which takes a parameter that is a 2 dimensional array
>which it will never modify.  [...]  Except for [one] ANSI C compiler, all
>the ANSI C compilers here complain about the following:
>	extern void fn(const float colours[][3]);
>	static float colours[][3] = { { 1.0, 0.0, 0.0 } };
>	fn2(void) {
>		fn(colours);
>	}
>The complaint is the parameter in the call to fn() does not match the
>prototype.

3.7.1, page 83 lines 23 to 24:  "A declaration of a parameter as 'array of
type' shall be adjusted to 'pointer to type', [...]".

The parameter declaration says array (unknown size) of array (size 3) of
const float.  It is adjusted to be pointer to array (size 3) of const float.

3.3.2.2, page 41 lines 21 to 23 (a Constraint):  "Each argument shall have
a type such that its value may be assigned to an object with the unqualified
version of the type of its corresponding parameter."  Now the unqualified
version of a type only deletes the top level of qualification (if the top
level was qualified).  For example, the unqualified version of const pointer
to const is still pointer to const.

Thus the unqualified version of the parameter is still pointer to array
(size 3) of const float.

The identifier in the argument in the call has type array (size 1) of array
(size 3) of float, and gets converted to be pointer to array (size 3) of float.

3.3.16.1, pages 53 to 54, specifies what may be assigned to what.  This
assignment is not permitted.  The closest possibility would be pointers
to qualified or unqualified versions of compatible types (with a further
condition that is moot here), but array of const is not compatible with
array of non-const.

Thus the constraint in 3.3.2.2 is violated.

This proves that one of your purported ANSI C implementations is not a
genuine ANSI C implementation (if you invoked it as directed by the vendor).

>The compilers seem much happier if the call is changed to:
>		fn((const float (*)[3])colours);

The cast specification says pointer to array (size 3) of const float.
This type matches the parameter's type.

>[Another implementation's] complaint is at least amusing:
>const.c:9:  error:  In this statement, the referenced type of the
>pointer value "colours" is "array [3] of float", which is not compatible
>with "array [3] of float".

The standard requires a diagnostic for the program, but not that the
diagnostic be accurate or meaningful.  Only market forces can do that.
--
Norman Diamond                diamond@jit.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
Pardon me?  Or do I have to commit a crime first?