Multidimentional arrays generate an unexpected error

[earnol]

Since the commit b247698 and associated pull request #157364 the following code:

#include <stdio.h>
int afunc(unsigned long * v)
{
    return v != NULL;
}
unsigned long mdarr[5][6];
unsigned long sdarr[30];
int main()
{
  afunc(sdarr);
  afunc(mdarr);
  printf("mdarr = %zu \n", sizeof(mdarr));
  printf("sdarr = %zu \n", sizeof(sdarr));
  return 0;
}

generate an error:
error: incompatible pointer types passing 'unsigned long[5][6]' to parameter of type 'unsigned long *' [-Wincompatible-pointer-types].
Please see godbolt example.

However the ISO/IEC 9899:1999 standard in 6.5.2.1 Array subscripting says:

If E is an n-dimensional array (n ≥ 2) with dimensions i × j × . . . × k, then E (used as other than an lvalue) is converted to a pointer to an (n − 1)-dimensional array with dimensions j × . . . × k. If the unary * operator is applied to this pointer explicitly, or implicitly as a result of subscripting, the result is the pointed-to (n − 1)-dimensional array, which itself is converted into a pointer if used as other than an lvalue.

effectively requiring compatibility between multidimensional array and pointer. Thus it looks like a diagnostics should not be generated in such case as standard compliant compiler should guarantee compatibility between all 3 types unsigned long *, unsigned long [5][6], unsigned long [30] .

[Sirraide]

GCC diagnoses this too so I’m not sure this is right candidly. I’m also not an expert on the C standard though (and the person who I’d normally ask about this is currently on a sabbatical)

[Sirraide]

GCC diagnoses this too

Looks like pretty much every C compiler on godbolt diagnoses this actually.

[Sirraide]

However the ISO/IEC 9899:1999 standard in 6.5.2.1 Array subscripting says:

If E is an n-dimensional array (n ≥ 2) with dimensions i × j × . . . × k, then E (used as other than an lvalue) is converted to a pointer to an (n − 1)-dimensional array with dimensions j × . . . × k. If the unary * operator is applied to this pointer explicitly, or implicitly as a result of subscripting, the result is the pointed-to (n − 1)-dimensional array, which itself is converted into a pointer if used as other than an lvalue.

effectively requiring compatibility between multidimensional array and pointer. Thus it looks like a diagnostics should not be generated in such case as standard compliant compiler should guarantee compatibility between all 3 types unsigned long *, unsigned long [5][6], unsigned long [30] .

Also, that section in particular is about subscripting; the sentence before the part you quoted is

Successive subscript operators designate an element of a multidimensional array object

so this doesn’t seem like it would apply here given that no subscripting is taking place in the call to afunc(mdarr).

[earnol]

I do not think one needs to be an expert here as we have a standard an it is the one and single source of truth. And my reading tells me that while the whole paragraph indeed talks about subscripting of multidimentional array it (please follow my inferences):

1. Does establish equivalence unary * operator is applied to this pointer explicitly, or implicitly as a result of subscripting between results of the the subscripting.
2. Thus we have an object, which when applied 2 different operations * and subscripting that is required to produce identical results for the elements access.
3. Pointer is following the same semantics to provide access to it's element as required equivalency stated in the same paragraph.
4. Thus pointers are indeed compatible for the elements access purposes.
5. There is no standard requirement (or at least i have not found it) to have those pointers to be incompatible for any other purposes or declared as an UB.
6. From my godbolt experiments i concluded in all compilers the explicit cast produces the compatible pointer for ALL valid purposes. Other purposes i checked are address arithmetic and comparisons.
7. The warning currently claims pointer incompatibility which is not correct from both piratical and standard induced (for element access) point-of-views.
8. Thus the warning or moreover the error as is it is spelled now is incorrect and confusing to the developer and should be addressed as it warns about incompatibility, which is not actually here.

PS: At the end of the day as Hu Fuming stated: "Practice is the Sole Criterion for Testing Truth" (C)

[Sirraide]

So regarding this and what you said on the pr, I agree that it would intuitively make sense to allow this, but I still can’t find any place in the C standard that explicitly allow this (unless I missed a section somewhere, which is possible because I at least generally find it hard to find anything in the C standard); I don’t think it’s valid to make any such inference from how subscripting or dereferencing work (and if it’s supposed to be, I’d say the C standard needs to be revised because it’s entirely unclear to me how that would be a valid conclusion).

(Side note: I do see several mentions that this conversion applies if the array is ‘used as other than an lvalue’, but I have no idea what that’s supposed to mean, because I don’t think it’s possible to turn an array declaration into an rvalue of array type.)

You also mention that just because one or more compilers implement something a certain way doesn’t mean that they’re correct, and I agree with that, but at the same time I also find it unlikely that every C compiler got this wrong—though of course it’s not impossible. But at least in my experience, when all compilers (that I can find at least) diagnose something that I think is valid, that’s usually a sign that I’m missing something.

CC @cor3ntin @erichkeane @shafik for thoughts.

[shafik]

I believe the C FAQ backs up how this currently implemented My compiler complained when I passed a two-dimensional array to a function expecting a pointer to a pointer. in particular:

... by which arrays decay into pointers is not applied recursively. ...

[earnol]

@shafik, thank you very much for the link. The statement in the FAQ is definitely correct and I'm fully backing it up. Applying array decay recursively does NOT makes sense because otherwise following this logic for int a[2][3][4] we need to establish equivalence with int *** type which makes zero sense.
If you will look into proposed PR it makes compiler not throwing error between int a[2][3][4] and int * as int * represents the same "flattened" (using FAQ term) array with it's shape lost inside implicit conversion.
So I'm not proposing to use array decay recursively (and never was), but instead I'm challenging the decision of throwing out error when developer implicitly "flatten" the array. Please note, now this error is enabled by default, which, by all means establish some level of severity standard.
My point is the conversion is actually compatible as we are not hitting undefined behavior or something serious, the conversion loosing the shape of array and this is it. Such conversion does NOT introduce any incompatibility.
May be it would be wise not ignore it completely like in my PR, but introduce a warning (not an error!) about implicit array "flattening". What do you think about such approach?

@Sirraide loosening this restriction in case multidimensional array on the left side makes zero sense and my change does not cover this case. I also agree in your broader statement about all compilers, however please note that "diagnose something" is not equal to "throw an error about pointer incompatibility".
For example msvc says: "warning C4024: 'afunc': different types for formal and actual parameter 1" which is correct because types are indeed different. My point is throwing an error in such case is not correct and overreacting. May be some diagnostics is due in such case as shape of array is lost and user should be warned about it.

[cor3ntin]

I think this is inventing language features on the fly.

The standard says (lvalue conversion)

Except when it is the operand of the sizeof operator, or the _Countof operator, or typeof operators,
or the unary & operator, or is a string literal used to initialize an array, an expression that has type
"array of type" is converted to an expression with type "pointer to type" that points to the initial
element of the array object and is not an lvalue. If the array object has register storage class, the
behavior is implementation-defined.

This cannot be interpreted as "convert array of array of type to pointer to type"

What we might want to consider (if this is really an issue for folks) is to put that case under a different warning flags (-Wincompatible-array-pointer-types for example) that can be disabled independently.

Not warning at all on such conversion would require either

• a small RFC
• a WG14 paper (we might want to wait for @AaronBallman to come back to weight on the pertinence of such paper)

Note that these specific conversion rules are the same in C++.