You should be able to generate machine code without the need of any runtime, like you can with C.

And yes, for new APIs you could just change the order, but it does help also with legacy APIs. It does even when not using pointers to arrays: https://godbolt.org/z/TM5Mn95qK (I agree that new APIs should pass a pointer to a VLA).

(edited because I am agreeing with most of what you said)

I know that was a common opinion pre-C23, but it feels like the committee trying to reshape the world to their desires (and their designs). It's a longstanding convention that C APIs accept (address, length) pairs in that order. So changing that will already get you a score of -4 on the Hard to Misuse List[1], for "Follow common convention and you'll get it wrong". (The sole old exception in the standard is the signature of main(), but that's somewhat vindicated by the fact that nobody really needs to call main(); there is a new exception in the standard in the form of Meneide's conversion APIs[2], which I seriously dislike for that reason.)

The reason I was asking is that 'uecker said it was requested at the committee draft stage for C23 by some of the national standards orgs. That's already ancient history of course, but I hoped the idea itself was still alive, specifically because I don't want to end up in the world where half of C APIs are (address, length) and half are (length, address), when the former is one of the few C conventions most everyone agrees on currently.

[1] https://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html

[2] https://thephd.dev/_vendor/future_cxx/papers/C%20-%20Restart...

  $ make texe
  cc -g -O2 -std=c11 -Wall -Wextra -Wpedantic -Werror   -c -o test.o test.c
  test.c: In function ‘do_test_formatSmallElem’:
  test.c:108:9: error: ‘matSmallElemFormat’ accessing 8 bytes in a region of size 2 [-Werror=stringop-overflow=]
    108 |         matSmallElemFormat(elem, buffer);
        |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  test.c:108:9: note: referencing argument 2 of type ‘char *’
  In file included from test.c:8:
  mat/display.h:17:6: note: in a call to function ‘matSmallElemFormat’
     17 | void matSmallElemFormat(mElem elem, char buffer[static matSmallElemLen]);
        |      ^~~~~~~~~~~~~~~~~~~~~
  cc1: all warnings being treated as errors
  make: *** [<builtin>: test.o] Error 1

   struct foo
   {
     size_t elements;
     int data[];
   };

   foo foo123 = {.elements = array_size(data), .data = {1, 2, 3}};

   str s123 = {.sz = strlen(.str), .str = "123"};