Syntax for VLAs as a function parameter - c

Question

I wrote the naivest matrix multiplication code to complete my understanding to C99 VLAs. What confuses me a bit is when I declare a pointer to a VLA in the argument list at function definition.
For example, in fill_matrix_randomly, the argument m declared as double (*m)[n_cols] compiles fine as it should. double (*m)[*] is a compile error because [*] can only appear in the declaration. double (*m)[] is also an error because I cannot access an array of incomplete type. Nothing weird until now, but. double (*m)[n_rows] compiles fine and even runs fine? double (*m)[1] or double (*m)[2] works too, and I got really confused here. Help me be less confused.
#include <stdio.h>
#include <stdlib.h>
static void fill_matrix_randomly(int, int, double (*)[*]);
static void print_matrix(int, int, double (*)[*]);
static void multiply_matrices(int, int, int, double (*restrict)[*],
double (*restrict)[*], double (*restrict)[*]);
int main(void) {
const int a = 1, b = 3, c = 5;
double m[a][c], m2[a][b], m3[b][c];
fill_matrix_randomly(a, b, m2);
fill_matrix_randomly(b, c, m3);
multiply_matrices(a, b, c, m, m2, m3);
print_matrix(a, b, m2);
print_matrix(b, c, m3);
print_matrix(a, c, m);
}
static void fill_matrix_randomly
(int n_rows, int n_cols, double (*m)[n_cols]) {
for (int i = 0; i < n_rows; ++i) {
for (int j = 0; j < n_cols; ++j) {
m[i][j] = (double)rand() / RAND_MAX + 1;
}
}
}
static void print_matrix(int n_rows, int n_cols, double (*m)[n_cols]) {
for (int i = 0; i < n_rows; ++i) {
printf("[ ");
for (int j = 0; j < n_cols; ++j) {
printf("%.3f", m[i][j]);
if (j != n_cols - 1) {
printf(", ");
} else {
printf(" ]\n");
}
}
}
putchar('\n');
}
static void multiply_matrices
(int n, int m, int p, double (*restrict r)[p],
double (*restrict a)[m], double (*restrict b)[p]) {
for (int i = 0; i < n; ++i) {
for (int j = 0; j < p; ++j) {
double sum = 0;
for (int k = 0; k < m; ++k) {
sum += a[i][k] * b[k][j];
}
r[i][j] = sum;
}
}
}

Answer 1

double (*m)[n_rows] compiles fine and even runs fine
If you declared your function parameter with type double (*)[n_rows], but passed an argument of type double (*)[n_columns], and n_rows is different from n_columns, then the behavior is undefined.
The same applies to double (*m)[1] and double (*m)[2] variants.
Parameter passing requires parameter type to be compatible with argument type. In case of pointers to arrays, the pointers have to point to compatible array types. In your case the following applies
6.7.5.2 Array declarators
6 For two array types to be compatible, both shall have compatible element types, and if both size specifiers are present, and are
integer constant expressions, then both size specifiers shall have the
same constant value. If the two array types are used in a context
which requires them to be compatible, it is undefined behavior if the
two size specifiers evaluate to unequal values.
Obviously, nobody can reasonably expect such violations to be caught at compile time, since the compiler generally cannot predict and enforce run-time relationships (VLA sizes) at compile time.
After committing this violation (which by itself is sufficient to trigger UB), you proceed to commit another one by performing out of bounds access to your array inside fill_matrix_randomly.
As for running it... where you got the idea that the code with double (*m)[n_rows] "runs fine" is not clear to me. A quick experiment shows that lying like that to the compiler results in either improperly filled array, if you are lucky
http://coliru.stacked-crooked.com/a/6032864f2baa2eae
or a crash if you are not so lucky
http://coliru.stacked-crooked.com/a/7ba1002e3150bd1c

Answer 2

The definition:
static void print_matrix(int n_rows, int n_cols, double (*m)[n_cols]) {
…
}
says that m is a pointer to an array where each element of the array has n_cols columns. This is perfectly kosher.
The options with a constant row size (double (*m)[1] or double (*m)[2]) work as well as the one with variable row size.
You might also care to note that this minor variant on your code also compiles and runs and (because there is no seeding of the random number generator) produces the same answer:
#include <stdio.h>
#include <stdlib.h>
static void fill_matrix_randomly(int, int, double[*][*]);
static void print_matrix(int, int, double[*][*]);
static void multiply_matrices(int, int, int, double[*][*],
double[*][*], double[*][*]);
int main(void)
{
const int a = 1, b = 3, c = 5;
double m[a][c], m2[a][b], m3[b][c];
fill_matrix_randomly(a, b, m2);
fill_matrix_randomly(b, c, m3);
multiply_matrices(a, b, c, m, m2, m3);
print_matrix(a, b, m2);
print_matrix(b, c, m3);
print_matrix(a, c, m);
}
static void fill_matrix_randomly(int n_rows, int n_cols, double m[n_rows][n_cols])
{
for (int i = 0; i < n_rows; ++i)
{
for (int j = 0; j < n_cols; ++j)
m[i][j] = (double)rand() / RAND_MAX + 1;
}
}
static void print_matrix(int n_rows, int n_cols, double m[n_rows][n_cols])
{
for (int i = 0; i < n_rows; ++i)
{
printf("[ ");
for (int j = 0; j < n_cols; ++j)
{
printf("%.3f", m[i][j]);
if (j != n_cols - 1)
printf(", ");
else
printf(" ]\n");
}
}
putchar('\n');
}
static void multiply_matrices(int n, int m, int p, double r[n][p],
double a[n][m], double b[m][p])
{
for (int i = 0; i < n; ++i)
{
for (int j = 0; j < p; ++j)
{
double sum = 0;
for (int k = 0; k < m; ++k)
sum += a[i][k] * b[k][j];
r[i][j] = sum;
}
}
}

Answer 3

You are required to specify the sizes of all but the first dimension. This is because multidimensional arrays are stored in contiguous memory locations, so the dimensions are needed to compute the actual offset from the starting address to find each element in the first dimension.
Your two-dimensional array has rows and columns (in a high-level sense). It might look like this in memory:
Row 0 | 1 | 2 ...
+----+----+----|----+----+----|----+----+
| | | | | | | | | ...
+----+----+----|----+----+----|----+----+
Col 0 1 2 | 0 1 2 | 0 1
An array access in the form of array[i][j] is equivalent to an addition and dereference of the pointer array: *(*(array + i) + j).
array + i is used to offset you to row number i (and dereferenced to give you the array held there), and j is used to take you a bit further to the jth element in that row. It is clear that to get you the correct row offset, the compiler has to know the size of each row.
In the example above, for instance, the compiler needs to know to skip 3 memory locations/units of data to advance from row to row.
The more complete formula is as follows (note that the compiler does this expansion automatically):
*((array + (i * #cols/row * sizeof(array elem))
+ (j * sizeof(array elem)))
It's clear to see that what needs to be known ahead of time is sizeof(array elem) and #cols/row.
The sizeof(array elem) is known since you specify the base type being stored in your multidimensional array (in your case, double). But the #cols/row has to be specified by the programmer in order for the compiler to compute offsets correctly.
In all your examples of working code, you are giving it a concrete value of columns contained in each row. However, in all of them, you will get unexpected behavior, because your array of a specific size is being treated as an array of a different size. By specifying incorrect or mismatched sizes, you are invoking undefined behavior since there is fundamentally a mismatch of type in the parameter and the argument provided. You declared the 2D array with x columns but are passing it as an array with y columns.
Declaring an array whose second dimension is 3 and passing it to a function that accepts an array with second dimension 2 looks like this, where the same memory is interpreted in two different ways:
Row 0 | 1 | 2 ...
+----+----+----|----+----+----|----+----+
| | | | | | | | | ...
+----+----+----|----+----+----|----+----+
Col 0 1 2 | 0 1 2 | 0 1
Row 0 | 1 | 2 | 3 ...
+----+----|----+----|----+----|----+----+
| | | | | | | | | ...
+----+----|----+----|----+----|----+----+
Col 0 1 | 0 1 | 0 1 | 0 1
You can see that accessing array[1][0] gives you two completely different results, the first being the expected result and the second being the result rendered due to type mismatch.