Safely passing arrays in C

Question

In C, passing arrays gives no information as to the length of the array passed, since they decay to raw pointers. This leaves the passing of pointer information up to the programmer. I demonstrate a few methods for doing so below, and discuss some pros and cons in the comments.

// only works if array has not already decayed,
// passing a raw pointer produces incorrect results 
#define foo(arr) _foo(arr, sizeof arr / sizeof *arr)
// most straightforward option, but can be unsafe
void _foo(int *arr, size_t n)
{
    for (size_t i=0; i < n; i++) {
        // code
    }
}

// very dangerous if array not prepared properly
// simple usage and implementation, but requires sentinel value
void bar(int *arr /* arr must end in -1 */ ) 
{
    for (size_t i=0; arr[i] != -1; i++) {
        // code
    }
}

/* doesn't provide type safety, pointless
// simplifies usage, still hacky in implementation
#define baz(arr) _baz(sizeof arr / sizeof *arr, &arr)
// safest option, but complex usage and hacky implementation
void _baz(size_t n, int (*pa)[n])
{
    int *arr = *pa;
    for (size_t i=0; i < n; i++) {
        // code
    }
}
*/

Are there any other methods I didn't consider? Are there more pros and cons I missed? Overall, what method would you consider to be the best for general use? Which method do you use?

The most common approach seems to be the first option with no macro. Is using the third option with the macro considered to be bad practice? To me it seems the most robust.

I see this question, however it does not mention the third method, and given that it was asked nearly 12 years ago I wouldn't be surprised if new insights could be gained.

EDIT: Upon further inspection, it seems option 3 only provides pointer type safety when the function takes a fixed size array, I incorrectly assumed the method from this answer would extend to varaiable length arrays and neglected to test it.

I'm not sure if the changes in C23 mentioned in chux's answer would fix this method, or if it could be simplified to baz(size_t n, int arr[n]). Reading through it, nothing in the linked paper seems to suggest int arr[n] would no longer decay to int *arr, but I may be wrong.

Answer 1

You are wrong in some assumptions:

// only works if array has not already decayed,
// passing a raw pointer produces incorrect results 

Array is not decayed into a pointer at runtime; array decayment consists of a static conversion made at compilation time by converting the array declaration into a pointer declaration. So you declare a pointer instead, with no conversion at runtime, but evaluating the address of the first array element — this is how the array name is interpreted by the compiler — and passing it as the required pointer.

Originally, pointers were declared by appending [] at the end, and * for pointer declarations was introduced later. (Today, if you declare a pointer this way — except in parameter declarations, in that it decays to a pointer — a declaration like

/* global file scope */
int arr[];

is an incomplete type declaration that is completed at compilation time by assigning the array just one element, and a warning is issued. (I don't actually know if this is a standard requirement or a compiler extension):

pru.c: At top level:
pru.c:5:5: warning: array ‘ptr’ assumed to have one element
    5 | int ptr[];
      |     ^~~

A parameter declaration like:

void _foo(int *arr, size_t n)

never declares an array, but a pointer. Even if you do:

void _foo(int arr[], size_t n)

or

void _foo(int arr[7], size_t n)

that's an incomplete array declaration that does decay into a pointer declaration int *arr (indeed, a pointer was declared using [] in the original draft of C by K&R, and the * notation was included later, and the now different meaning indicated above was issued instead)

A parameter declaration (and this is the only case in which we can talk about decayment) is when you do a full array declaration (complete or incomplete) as in:

void _foo(int arr[7], size_t n)

or

void _foo(int arr[], size_t n)

in that case, the array declaration is said to decay to a pointer declaration, equivalent to:

void _foo(int *arr, size_t n)

In any case, array decayment to a pointer is done because an array is not an usable object as a whole and the compiler has no provision to allow you to calculate the array size, so in case you do e.g.

#include <stdio.h>

#define P(_lbl) printf("%s: size of %s == %zd\n", __func__, _lbl, sizeof arr)
void foo1(int arr[7])
{
   P("arr[7]");
}
void foo2(int arr[])
{
   P("arr[]");
}
void foo3(int *arr)
{
   P("*arr");
}
int main()
{
    int arr[3] = {0, 0, 0};
    P("arr[3]");
    foo1(arr);
    foo2(arr);
    foo3(arr);
}

will result in (showing the decayment in the array cases):

$ a.out
main: size of arr[3] == 12  -- in main, no array decayment happens
foo1: size of arr[7] == 8   -- in foo1, array decays into a pointer.
foo2: size of arr[] == 8    -- in foo2, array again decays into a pointer.
foo3: size of *arr == 8     -- in foo3, no decayment happens, but a pointer is declared.
$ _

Decayment of arrays into pointers is a completely supported feature, that doesn't happen at runtime (code is written to use pointers, and the array size is never known in the function body) You have seen that in main(), the array is declared as a local variable, but it doesn't decay into a pointer, as it does neither decay in a global variable.

In other languages that allow you to pass arrays as parameters, and you can know the array size that is passed from the outside to the inside of a function, the array size (being this the total size in bytes, or the number of elements) must be passed, hidden, as a parameter to the function, and this will allow array bound checking, or they are passed as references to objects (in OOP) that allow you to pass it hidden in the object instance representation. No magic is expected here. In C, only parameters actually declared are passed, and when an array is passed, the compiler converts all the array accesses into pointer accesses (and only at the first array level, no recursivity is done here) so a complex declaration like:

int foo(int(*arr[7][3])(void));

will decay into:

int foo(int(*(*arr)[3])(void));

this is a pointer to an array of three pointers to functions that take no parameters and return an integer.

Answer 2

Are there any other methods I didn't consider?

Let's make a deal and consider door #4: Use size and then pointer: (size_t n, int a[n]).

C23 is coming out with a change: Variably-Modified Types to allow "possibly at compile-time with stronger analysis".
This works with modern compilers to form better code and detect weaknesses.

void foo_vla(size_t n, int arr[n]);

Available in C23 even if VLA, as an object, is not supported.
Available in C11/C17 with VLA support.
Available in C99 as that always supports VLA.
Available in C89 as void foo_val(size_t n, int arr[/*n*/]);, but then we reduce analyzability.

This is like the good answer to that old question not considered by OP and is even more relevant with C23.