3 ms·

Genuinely curious: why don't suggest that to WG14? (WG14) is the ISO workgroup which maintains the C specification.

Arch-TK 4y ago
And what would it achieve to "fix" this (without re-designing the rest of the language)? Every piece of code such as: int a[SIZE]; foo(a, SIZE); Would have to be rewritten to: int a[SIZE]; foo(&a[0], SIZE); And this additional noise would just make C harder to write for no reason. Rather than making C harder to write, just pick a different programming language.
- WalterBright 4y ago
  The article I referenced says how this is fixed. It is not harder to write at all.
  - Arch-TK 4y ago
    Adding fat pointers to C is a major redesign and the fact that the explanation fits within a short blog post doesn't make it an easy fix. If you don't add fat pointers (thereby requiring a major re-design of the language and causing an endless amount of pain with regards to ABIs etc) then the solution, which involves removing the implicit conversion of an array to a pointer to its first element in expressions where it is not used as an operand of the sizeof operator, unary & operator or as a string literal used to initialise an array, certainly DOES make it harder to write C.
    - WalterBright 4y ago
      > Adding fat pointers to C is a major redesign No, it isn't. I implemented it in D, and know what is involved. I've written two C compilers, as well. > the fact that the explanation fits within a short blog post doesn't make it an easy fix. Correct, but since I've actually done it, I'm in a good position to say it is an easy fix.
      - Arch-TK 4y ago
        D is not C, your experience writing compilers doesn't make this an easy fix. The problem is not the cost of implementing this (trivial) it is the cost to the nature of the C programming language. This will never get past the C WG and will cause massive disruption to how C is used these days. The point is, it's an easy fix if you make a new language, it is a difficult fix if you want to call the end result C.
- mhh__ 4y ago
  A tool to do this transformation would not be hard.
  - Arch-TK 4y ago
    That's not the point though. You would still have the same underlying issue (no way to intrinsically tie the size of the memory addressable using a pointer to the pointer) and the disadvantage of code being less clear (are you actually passing the pointer to just one element, are you trying to pass a pointer to the beginning of the whole array?) The key takeaway is that the implicit conversion from array to pointer to first element is not the problem with C. The problem with C is that it's a very limited language which would require a re-design (e.g. fat pointers and implicit range checks everywhere, which, while solving one problem, wouldn't really solve ALL or even most of the problems with pointers). I think that, for its time, C was a decent improvement over assembly programming. I think that in the current day and age if you are writing C and use modern tooling as well as follow a set of good guidelines (as well as have the right mentality and don't ACTUALLY treat is as high level assembly) it is possible to write more or less safe C in small doses. For anything else I think the correct solution is not to ponder how to fix C, or pretend like there's just one problem with it, instead the solution is to use a better language.

And what would it achieve to "fix" this (without re-designing the rest of the language)? Every piece of code such as: int a[SIZE]; foo(a, SIZE); Would have to be rewritten to: int a[SIZE]; foo(&a[0], SIZE); And this additional noise would just make C harder to write for no reason. Rather than making C harder to write, just pick a different programming language.

WalterBright 4y ago
The article I referenced says how this is fixed. It is not harder to write at all.
- Arch-TK 4y ago
  Adding fat pointers to C is a major redesign and the fact that the explanation fits within a short blog post doesn't make it an easy fix. If you don't add fat pointers (thereby requiring a major re-design of the language and causing an endless amount of pain with regards to ABIs etc) then the solution, which involves removing the implicit conversion of an array to a pointer to its first element in expressions where it is not used as an operand of the sizeof operator, unary & operator or as a string literal used to initialise an array, certainly DOES make it harder to write C.
  - WalterBright 4y ago
    > Adding fat pointers to C is a major redesign No, it isn't. I implemented it in D, and know what is involved. I've written two C compilers, as well. > the fact that the explanation fits within a short blog post doesn't make it an easy fix. Correct, but since I've actually done it, I'm in a good position to say it is an easy fix.
    - Arch-TK 4y ago
      D is not C, your experience writing compilers doesn't make this an easy fix. The problem is not the cost of implementing this (trivial) it is the cost to the nature of the C programming language. This will never get past the C WG and will cause massive disruption to how C is used these days. The point is, it's an easy fix if you make a new language, it is a difficult fix if you want to call the end result C.
mhh__ 4y ago
A tool to do this transformation would not be hard.
- Arch-TK 4y ago
  That's not the point though. You would still have the same underlying issue (no way to intrinsically tie the size of the memory addressable using a pointer to the pointer) and the disadvantage of code being less clear (are you actually passing the pointer to just one element, are you trying to pass a pointer to the beginning of the whole array?) The key takeaway is that the implicit conversion from array to pointer to first element is not the problem with C. The problem with C is that it's a very limited language which would require a re-design (e.g. fat pointers and implicit range checks everywhere, which, while solving one problem, wouldn't really solve ALL or even most of the problems with pointers). I think that, for its time, C was a decent improvement over assembly programming. I think that in the current day and age if you are writing C and use modern tooling as well as follow a set of good guidelines (as well as have the right mentality and don't ACTUALLY treat is as high level assembly) it is possible to write more or less safe C in small doses. For anything else I think the correct solution is not to ponder how to fix C, or pretend like there's just one problem with it, instead the solution is to use a better language.