4 ms·

> I mean the inability to pass an array to a function as an array, even if it is declared to be an array. This is possible for fixed-length arrays using 'myTyp

> I mean the inability to pass an array to a function as an array, even if it is declared to be an array. This is possible for fixed-length arrays using 'myType (*myVar)[size]' as the argument type. https://stackoverflow.com/a/51527502 https://stackoverflow.com/a/51527502

chongli 3y ago
But in reality is of limited utility. This fixes the size of the array in the function signature. If I want to write a function that returns the sum of all the integers in an array I would need to write a new function for each size of array, a non-starter. The annoying thing about this is that the array is just sitting there on the stack of the calling function. The size is completely known at compile time. But it gets thrown away as soon as you call a function.
- a_nop 3y ago
  Supplying the array length to such a summing function is not a big deal. The compiler is not likely to handle this poorly. Probably gets inlined. If the syntax is the problem, yeah, if you want first class data structures you might not like C.
  - chongli 3y ago
    you might not like C The title of the article is “C’s biggest mistake.” If you’re going to rebut the article, do so. Otherwise your reply just comes off as “this is the way it is, deal with it!” which is a pretty shallow dismissal.
- tialaramex 3y ago
  > This fixes the size of the array in the function signature That's what an array is. Fixed size. If we want to talk about a slice of some runtime determined amount of a thing then we need fat pointers, and C doesn't provide any fat pointer types so it's not a surprise to find it can't do slices.
  - chongli 3y ago
    No, I am not talking about a runtime-allocated structure. I’m talking about a function that can accept and operate on arrays of different sizes, all of which are fixed size at their declaration site, and all stored on the stack. There is no reason this shouldn’t be possible. It should not require fat pointers at all because the size information is known at compile time.
    - School-Cotton 3y ago
      AFAICT you’d either have to pass the length at runtime somehow, or treat the function as a generic/template and generate a separate version for each separate N it’s called with. The latter would be pretty far from the ethos of C, imo.
      - chongli 3y ago
        This could be done by storing the length of the array before the first element. It wouldn’t even need to be done in all cases, only if the length is actually used.
      - usefulcat 3y ago
        > AFAICT you’d either have to pass the length at runtime somehow This is exactly the solution proposed in TFA..
senkora 3y ago
Your link points out that this decays to a raw pointer in all cases and is not enforced by the compiler.
- joshuaissac 3y ago
  It does not. The decay is for the arr[size] form. > using the int array1[2]; like this: arraytest(array1); causes array1 to automatically decay into an int . > HOWEVER, if you take the address of array1 instead and call arraytest(&array1), you get completely different behavior! > Now, it does NOT decay into an int
pornel 3y ago
There's C99 `arr[static size]` function argument syntax, but it's still not a proper slice type. Compilers may warn about incorrect direct uses of such argument (although last time I checked they don't), but it still decays to a pointer. You can't use this as a type of a variable or a struct field. There's no way to make subslices (safe pointer arithmetic) without losing the arrayness argument magic, etc.

chongli 3y ago

But in reality is of limited utility. This fixes the size of the array in the function signature. If I want to write a function that returns the sum of all the integers in an array I would need to write a new function for each size of array, a non-starter. The annoying thing about this is that the array is just sitting there on the stack of the calling function. The size is completely known at compile time. But it gets thrown away as soon as you call a function.

a_nop 3y ago
Supplying the array length to such a summing function is not a big deal. The compiler is not likely to handle this poorly. Probably gets inlined. If the syntax is the problem, yeah, if you want first class data structures you might not like C.
- chongli 3y ago
  you might not like C The title of the article is “C’s biggest mistake.” If you’re going to rebut the article, do so. Otherwise your reply just comes off as “this is the way it is, deal with it!” which is a pretty shallow dismissal.
tialaramex 3y ago
> This fixes the size of the array in the function signature That's what an array is. Fixed size. If we want to talk about a slice of some runtime determined amount of a thing then we need fat pointers, and C doesn't provide any fat pointer types so it's not a surprise to find it can't do slices.
- chongli 3y ago
  No, I am not talking about a runtime-allocated structure. I’m talking about a function that can accept and operate on arrays of different sizes, all of which are fixed size at their declaration site, and all stored on the stack. There is no reason this shouldn’t be possible. It should not require fat pointers at all because the size information is known at compile time.
  - School-Cotton 3y ago
    AFAICT you’d either have to pass the length at runtime somehow, or treat the function as a generic/template and generate a separate version for each separate N it’s called with. The latter would be pretty far from the ethos of C, imo.
    - chongli 3y ago
      This could be done by storing the length of the array before the first element. It wouldn’t even need to be done in all cases, only if the length is actually used.
    - usefulcat 3y ago
      > AFAICT you’d either have to pass the length at runtime somehow This is exactly the solution proposed in TFA..

senkora 3y ago

Your link points out that this decays to a raw pointer in all cases and is not enforced by the compiler.

joshuaissac 3y ago
It does not. The decay is for the arr[size] form. > using the int array1[2]; like this: arraytest(array1); causes array1 to automatically decay into an int . > HOWEVER, if you take the address of array1 instead and call arraytest(&array1), you get completely different behavior! > Now, it does NOT decay into an int

pornel 3y ago

There's C99 `arr[static size]` function argument syntax, but it's still not a proper slice type. Compilers may warn about incorrect direct uses of such argument (although last time I checked they don't), but it still decays to a pointer. You can't use this as a type of a variable or a struct field. There's no way to make subslices (safe pointer arithmetic) without losing the arrayness argument magic, etc.