So... don't use array syntax in the function prototype and definition? The proposal doesn't PROHIBIT passing a pointer, it would just offer an option to pass a fat array.
Re:C’s Biggest Mistake (2009)
by SV_BubbleTime on Saturday September 12, 2020 @08:06PM
(#24457024)
I think you mean fat pointer. And yea, that’s nice for people that don’t care their 4bit array has 64bits of native type reserved... I think other people would care.
So, I go back to the idea that it seems unlikely this would ever be an official C change.
I think you and I are talking past one another.
Currently, f(a[]) with declaration void f(int a[]) passes a pointer to the first element, with no additional overhead.
Under the proposal, f(a[]) with declaration void f(int a[]) passes a pointer to the first element, with no additional overhead.
Help me understand why "other people would care"? What is the negative impact on someone who would not use the a[..] functionality?
>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.