4 ms·

I expect that there are probably a few significant points of technical resistance: 1. Introducing a new syntactic token (`..`) when there are already a lot of

I expect that there are probably a few significant points of technical resistance: 1. Introducing a new syntactic token (`..`) when there are already a lot of those in C. 2. Transforming an argument `char foo[..]` to the argument pair `const size_t foo_dim, char * const foo` leaves out a ton of existing APIs that order their arguments differently or breaks their binary compatibility. 3. It doesn’t accommodate APIs where both an element size and element count are passed, e.g. `fread(3)`. C is a long-lived language so modifications like this have to work within a very large existing body of code. They can be made to work—blocks have worked out wonderfully, for example, by essentially saying they’re only for new APIs—but this type of extension requires a lot of consideration beyond “we could tweak the syntax and get this feature.”

WalterBright 3y ago
1. `..` doesn't conflict with anything else in C. 2. APIs designed around pointers will not work with this proposal. But it would provide motivation for those APIs to change, and of course it will take time. Just like it took time for C function prototyping to take hold. 3. That's right, it doesn't. > C is a long-lived language so modifications like this have to work within a very large existing body of code It doesn't break existing code in any way. However, code would have to be modified to take advantage of it, sure. Just like _Generic.
- eschaton 3y ago
  And then none of the benefits are available to existing code without a rewrite. That’s why some solutions to this involve applying attributes to function prototype arguments and variable declarations instead, so you don’t have to rewrite everything to discover and prevent bugs.
  - WalterBright 3y ago
    > And then none of the benefits are available to existing code without a rewrite. That's right. > That’s why some solutions to this involve applying attributes to function prototype arguments and variable declarations instead, so you don’t have to rewrite everything to discover and prevent bugs. In every case I've seen you have to rewrite the code to use bounds checking. Note that the proposed arrays can be trivially converted to pointers, so you can still interact with pointer interfaces, and even length+pointer interfaces, without rewriting those interfaces. I submit that the rewrite to using the proposed arrays is a lot easier than rewriting to use the explicit length+pointer.
pjmlp 3y ago
Certainly in 50 years they had enough time to consider it, plus we are now in C23, and new things have been added all the time, either by WG14, or compiler extensions that many developers clueless about ISO think of them as C.

WalterBright 3y ago

1. `..` doesn't conflict with anything else in C. 2. APIs designed around pointers will not work with this proposal. But it would provide motivation for those APIs to change, and of course it will take time. Just like it took time for C function prototyping to take hold. 3. That's right, it doesn't. > C is a long-lived language so modifications like this have to work within a very large existing body of code It doesn't break existing code in any way. However, code would have to be modified to take advantage of it, sure. Just like _Generic.

eschaton 3y ago
And then none of the benefits are available to existing code without a rewrite. That’s why some solutions to this involve applying attributes to function prototype arguments and variable declarations instead, so you don’t have to rewrite everything to discover and prevent bugs.
- WalterBright 3y ago
  > And then none of the benefits are available to existing code without a rewrite. That's right. > That’s why some solutions to this involve applying attributes to function prototype arguments and variable declarations instead, so you don’t have to rewrite everything to discover and prevent bugs. In every case I've seen you have to rewrite the code to use bounds checking. Note that the proposed arrays can be trivially converted to pointers, so you can still interact with pointer interfaces, and even length+pointer interfaces, without rewriting those interfaces. I submit that the rewrite to using the proposed arrays is a lot easier than rewriting to use the explicit length+pointer.

pjmlp 3y ago

Certainly in 50 years they had enough time to consider it, plus we are now in C23, and new things have been added all the time, either by WG14, or compiler extensions that many developers clueless about ISO think of them as C.