3 ms·

> Because that's how the machine sees C arrays. It would take an extra (invisible) parameter on the stack to implicitly pass the array size into the function, a

> Because that's how the machine sees C arrays. It would take an extra (invisible) parameter on the stack to implicitly pass the array size into the function, a thing which is very much against the spirit of C. It would only require a separate parameter if you needed to pass arbitrary-sized arrays. In this example, if the prototype contains the array size: int foo(char array[30]); It would not be difficult for the compiler to only allow arrays of that length to be passed as parameters, and no invisible parameters are necessary, assuming also that the function implementation made the same assumption of array length. Developers who handle arrays of arbitrary length tend to already encode a length parameter, it's this case where it looks to the developer like they are encoding a length value that is the deceptive/problematic case.

geocar 11y ago
> It would not be difficult for the compiler to only allow arrays of that length to be passed as parameters It would be extremely difficult for the compiler, without changes to the C spec and most ABIs, to simultaneously provide that protection for heap-allocated objects, for example: foo(malloc(30)); > Developers who handle arrays of arbitrary length tend to already encode a length parameter, it's this case where it looks to the developer like they are encoding a length value that is the deceptive/problematic case. The most common arrays of arbitrary length in C programs are almost certainly C "strings" which are usually 0-terminated instead of including a length value.
mortehu 11y ago
This is one of the many uses of the static keyword in C99: void ten(char foo[static 10]) { } void generates_warning() { char foo[3]; ten(foo); } This causes clang to emit the following warning: > warning: array argument is too small; contains 3 elements, callee requires at least 10
- merlincorey 11y ago
  The warning is true - it is "at least" 10: char ten(char foo[static 10]); char ten(char foo[static 10]) { return foo[1]; } void generates_no_warning(void); void generates_no_warning() { char foo[30]; ten(foo); } int main() { generates_no_warning(); } Modified also so it would build cleanly with -Weverything -Werror
  - uxcn 11y ago
    It avoids stepping on memory elsewhere in the program though. My personal preference for C99 and above is to pass the length as a parameter. int do_stuff(size_t len, int64_t arr[len]); It still suffers from the pointer decay problem, but it at least forces whoever is reading/writing the code to acknowledge the length.
- uxcn 11y ago
  How does that parse? I thought static was only a storage class.
  - syncsynchalt 11y ago
    When extending the language, the committee will often try to re-use existing reserved keywords to avoid colliding with a variable name in someone's code. Thus we have yet another overloading of "static" in C, the use of "auto" in C++11 (which worked out quite well), and interesting type names such as "long long" in both. When the committee breaks this rule (think nullptr in C++11) they first must choose a name which is suitably rare (and often a bit clunky as a result), they then scan for that name in large code corpuses, and evaluate how much work they are making for the maintainers of any codebase that's going to be compiled against a new compiler (and which may need to be modified to do so). Some languages (I'm thinking JS specifically) have keywords that are not in use but are still reserved in case they may be useful in the future.

geocar 11y ago

> It would not be difficult for the compiler to only allow arrays of that length to be passed as parameters It would be extremely difficult for the compiler, without changes to the C spec and most ABIs, to simultaneously provide that protection for heap-allocated objects, for example: foo(malloc(30)); > Developers who handle arrays of arbitrary length tend to already encode a length parameter, it's this case where it looks to the developer like they are encoding a length value that is the deceptive/problematic case. The most common arrays of arbitrary length in C programs are almost certainly C "strings" which are usually 0-terminated instead of including a length value.

mortehu 11y ago

This is one of the many uses of the static keyword in C99: void ten(char foo[static 10]) { } void generates_warning() { char foo[3]; ten(foo); } This causes clang to emit the following warning: > warning: array argument is too small; contains 3 elements, callee requires at least 10

merlincorey 11y ago
The warning is true - it is "at least" 10: char ten(char foo[static 10]); char ten(char foo[static 10]) { return foo[1]; } void generates_no_warning(void); void generates_no_warning() { char foo[30]; ten(foo); } int main() { generates_no_warning(); } Modified also so it would build cleanly with -Weverything -Werror
- uxcn 11y ago
  It avoids stepping on memory elsewhere in the program though. My personal preference for C99 and above is to pass the length as a parameter. int do_stuff(size_t len, int64_t arr[len]); It still suffers from the pointer decay problem, but it at least forces whoever is reading/writing the code to acknowledge the length.
uxcn 11y ago
How does that parse? I thought static was only a storage class.
- syncsynchalt 11y ago
  When extending the language, the committee will often try to re-use existing reserved keywords to avoid colliding with a variable name in someone's code. Thus we have yet another overloading of "static" in C, the use of "auto" in C++11 (which worked out quite well), and interesting type names such as "long long" in both. When the committee breaks this rule (think nullptr in C++11) they first must choose a name which is suitably rare (and often a bit clunky as a result), they then scan for that name in large code corpuses, and evaluate how much work they are making for the maintainers of any codebase that's going to be compiled against a new compiler (and which may need to be modified to do so). Some languages (I'm thinking JS specifically) have keywords that are not in use but are still reserved in case they may be useful in the future.