C's function prototypes, syntactic sugar added circa 1990, were transformative for C programming.

More specifically, at the moment, it evaluates to the size of the pointer itself, which is useless. On the other hand;

  static void
  foo(int a[..])
  {
    for (size_t i = 0; i < (sizeof a / sizeof int); i++)
    {
      // ...
    }
  }

The only thing I'd like to see is compatibility with the static keyword; so that you can declare it as a sized-array but still indicate a compile-time minimum number of array elements. At the moment, in C99, this does not compile without serious diagnostics which would immediately highlight the problem:

  #include <stdio.h>

  static void
  foo(int a[static 4])
  {
    for (size_t i = 0; i < 4; i++)
      printf("%d\n", a[i]);
  }

  int
  main(void)
  {
    int a[] = { 1, 2, 3 };
    foo(a);     // Passing an array with 3 elements to a function that requires at least 4 elements
    foo(NULL);  // Passing no array to a function that requires an array with at least 4 elements
    return 0;
  }



  demo.c:14:3: warning: array argument is too small; contains 3 elements, callee requires at least 4 [-Warray-bounds]
  demo.c:15:3: warning: null passed to a callee that requires a non-null argument [-Wnonnull]

Yes, it's not a lot of effort to manually add a size_t argument. But it is far too tedious and error-prone to expect a programmer to add all the bounds checks. Being able to effortlessly tell the compiler "please check for me" is the huge win.

The second huge win is that the array is type-checked. So if you pass it to another function, the compiler enforces that it must again be passed with the size included. You don't get that by manually adding a size argument.

If you're worried about performance test it and turn it off.

So those programmers might just use the sugared approach and avoid the problem of writing past the end of an array, without ever knowing how tedious and/or difficult debugging such problems can be. They might sort of never even realize that they dodged a bullet simply due to some sugar.

How do you see it?

>extern void foo(size_t dim, char *a);

And the like assumes that I have the space to waste a native type on every array. So if I’m using a 10 length array, I need to provision a native 32 or 64 bit value for “10”.

In embedded system this wouldn’t happen. At least not mine, I’m running up on limits all over the place even being careful with bitfields and appropriately sized types.

He’s right of course that foo(array[]) is converted to a pointer but that’s why I think you should always use array as a pointer so YOU know not to rely on its automatic protections.

I get the point; but I just don’t see C making this change.