4 ms·

C99 did that. void f(int len, char s[len]); void g(float m[static 16]); The first one is for variable-length arrays, the second one for fixed-length.

by lieks 2y ago

C99 did that. void f(int len, char s[len]); void g(float m[static 16]); The first one is for variable-length arrays, the second one for fixed-length. TCC even implements array bounds-checking. But because a lot of people were stuck using C89 for several decades (due to old compilers), and the syntax isn't that great, nobody even knows they exist. Personally, I think Dennis Ritchie's[a] proposed syntax[b] was much better: void f(char s[?]); [a] The creator of C. [b] https://www.bell-labs.com/usr/dmr/www/vararray.html https://www.bell-labs.com/usr/dmr/www/vararray.html

segfaultbuserr 2y ago
> and the syntax isn't that great, nobody even knows they exist. Linux kernel maintainers certainly do - they even invented a non-standard extension of C99's VLA notation (their own invention, not implemented in GCC)... In newer versions of the package "Linux man-pages", most libc functions are documented using a non-standard extension of that syntax. For example, the prototype of memcpy() now reads [0]: void *memcpy(void dest[restrict .n], const void src[restrict .n], size_t n); It means this function accepts two arrays (dest[] and src[]), with n bytes of data type "void", src[] is read-only ("const"), and both src[] and dest[] are non-overlapping ("restrict"). Two non-standard notations are used here: a "void" array with elements of unknown type (not allowed in C99), also, ".n" means "a variable in the argument list, but defined after this variable" (which is not allowed in C99). The equivalent C99 definition would be something similar to: void *memcpy(size_t n, char dest[restrict n], const char src[restrict n]); As more people are exposed to these man pages, the C99 syntax hopefully will have more publicity. Finally, C23 interestingly states that: > 15. Application Programming Interfaces (APIs) should be self-documenting when possible. In particular, the order of parameters in function declarations should be arranged such that the size of an array appears before the array. The purpose is to allow Variable-Length Array (VLA) notation to be used. This not only makes the code's purpose clearer to human readers, but also makes static analysis easier. Any new APIs added to the Standard should take this into consideration. [0] https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/man3/memcpy.3?id=c64cd13e002561c6802c6a1a1a8a640f034fea70 https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/... [1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2611.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2611.htm
guenthert 2y ago
> TCC even implements array bounds-checking. Optionally (command line option '-b') though and (somewhat perplexingly) only at run-time. The documentation hints at the run-time performance (and code size) impact.
- lieks 2y ago
  TCC doesn't do any optimization at all, so it shouldn't be that perplexing. But any compiler that does constant propagation, inlining and (ideally) integer range analysis can optimize away most run-time bounds-checks already. If GCC or clang did it, it would probably be fast enough.

by lieks 2y ago

segfaultbuserr 2y ago

> and the syntax isn't that great, nobody even knows they exist. Linux kernel maintainers certainly do - they even invented a non-standard extension of C99's VLA notation (their own invention, not implemented in GCC)... In newer versions of the package "Linux man-pages", most libc functions are documented using a non-standard extension of that syntax. For example, the prototype of memcpy() now reads [0]: void *memcpy(void dest[restrict .n], const void src[restrict .n], size_t n); It means this function accepts two arrays (dest[] and src[]), with n bytes of data type "void", src[] is read-only ("const"), and both src[] and dest[] are non-overlapping ("restrict"). Two non-standard notations are used here: a "void" array with elements of unknown type (not allowed in C99), also, ".n" means "a variable in the argument list, but defined after this variable" (which is not allowed in C99). The equivalent C99 definition would be something similar to: void *memcpy(size_t n, char dest[restrict n], const char src[restrict n]); As more people are exposed to these man pages, the C99 syntax hopefully will have more publicity. Finally, C23 interestingly states that: > 15. Application Programming Interfaces (APIs) should be self-documenting when possible. In particular, the order of parameters in function declarations should be arranged such that the size of an array appears before the array. The purpose is to allow Variable-Length Array (VLA) notation to be used. This not only makes the code's purpose clearer to human readers, but also makes static analysis easier. Any new APIs added to the Standard should take this into consideration. [0] https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/man3/memcpy.3?id=c64cd13e002561c6802c6a1a1a8a640f034fea70 https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/... [1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2611.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2611.htm

guenthert 2y ago

> TCC even implements array bounds-checking. Optionally (command line option '-b') though and (somewhat perplexingly) only at run-time. The documentation hints at the run-time performance (and code size) impact.

lieks 2y ago
TCC doesn't do any optimization at all, so it shouldn't be that perplexing. But any compiler that does constant propagation, inlining and (ideally) integer range analysis can optimize away most run-time bounds-checks already. If GCC or clang did it, it would probably be fast enough.