3 ms·
Your proposed fix in [the article](https://www.digitalmars.com/articles/C-biggest-mistake.html https://www.digitalmars.com/articles/C-biggest-mistake.html) is t
by _kst_ 4y ago
Your proposed fix in [the article](https://www.digitalmars.com/articles/C-biggest-mistake.html https://www.digitalmars.com/articles/C-biggest-mistake.html) is to add a new function declaration syntax:
void foo(char a[..]);
that causes an array argument to be passed as a "fat pointer", consisting of a pointer to the initial element of the array plus a `size_t` value for the array dimension.
Tentatively, I like the idea.
As you acknowledge, this wouldn't fix existing code, but writing new code to use this new feature doesn't look difficult. (But converting all existing C code would take approximately forever.)
How does the function access the dimension? Is there a new syntax for extracting the length from a fat pointer, or do you just propose extending the semantics of `sizeof`?
Is there an existing C compiler that implements this?
A minor question: Given the above declaration, would
char c = '?';
foo(&c);
be valid, treating `c` as a single-element array?
Finally, a very minor point: `...` is already a valid punctuator. I can't think of any ambiguities that would be introduced by adding `..` as a new symbol, but that might be just my lack of imagination. (Note that gcc uses `...` in its case range extension.)
- tadfisher 4y agoI would go all-in and make arrays a distinct type, so the only way to create an array is with the [..] syntax, and forbid implicit type compatibility between arrays and pointers (which would discard the dimension part of the array type). An explicit conversion (cast) from pointer-to-array should require the dimension as part of the type. So &c on a char should produce char, and &c on a char[20] should produce char[20].
- tylerhou 4y agoWhy not standardize something like std::span in C?
- pjmlp 4y agoLack of willigness.
- _kst_ 4y agoArrays are already distinct types. char c; &c; // type is char* char arr[20]; &arr; // type is char (*p)[20], pointer to array of 20 char (A small quibble: the term "type compatibility" in C doesn't mean implicit convertibility. Two types are compatible if they're literally the same type, and in just a few other cases. You can assign an int value to a long object, but int and long are not compatible, even if they happen to be the same size.) The problem with dropping implicit array-to-pointer conversion is that it would break most existing C code. It would be a great idea for a new language. Suggested reading: Section 6 of the comp.lang.c FAQ, <https://www.c-faq.com/ https://www.c-faq.com/>. The relationship between arrays and pointers in C is admittedly confusing; this is the best resource I know of for explaining it.