3 ms·

Arrays decaying to pointers is probably the biggest non-platform specific design oversight. As you said, it's easy to see where it came from, but it should've

by abcd_f 8mo ago

Arrays decaying to pointers is probably the biggest non-platform specific design oversight. As you said, it's easy to see where it came from, but it should've been fixed long ago.

1718627440 8mo ago
> but it should've been fixed long ago. Is 27 years for you not long ago enough? That's more than a generation away and closer to the invention of the language than today.
- pjmlp 8mo ago
  Worse than that, lets remember that WG14 rejected Dennis Ritchie proposal for fat pointers, and the C authors decided it was more fun to keep their own way with other programming languages than try to improve C from WG14. https://www.nokia.com/bell-labs/about/dennis-m-ritchie/vararray.pdf https://www.nokia.com/bell-labs/about/dennis-m-ritchie/varar...
  - abcd_f 8mo ago
    I read through the RFC and I think it's fair it was rejected, because this was ultimately a half-measure, with severe usability restrictions. Fat pointers are clearly a way to deal with arrays (and also get "slices" and non-zero terminated strings for free!), but it's just not possible to retrofit them into the language without breaking existing code.
  - 1718627440 8mo ago
    I think we are talking past each other. I was saying that passing an array with a size to a function was standardized 27 years ago, asking if that isn't long enough. Sure, some may don't like how it was standardized, but it is possible. Beside the sibling comment about this specific proposal, I also think that fat pointers don't belong in the C standard. There is nothing in the C standard that says that pointers on the abstract C machine don't come with the allocated size, in fact the behaviour is described as if they do. Pointers are essentially scoped by allocation. All that is missing is code for that in a C implementation, the language allows that just fine.

3 ms·

Arrays decaying to pointers is probably the biggest non-platform specific design oversight. As you said, it's easy to see where it came from, but it should've

by abcd_f 8mo ago

Arrays decaying to pointers is probably the biggest non-platform specific design oversight. As you said, it's easy to see where it came from, but it should've been fixed long ago.

1718627440 8mo ago
> but it should've been fixed long ago. Is 27 years for you not long ago enough? That's more than a generation away and closer to the invention of the language than today.
- pjmlp 8mo ago
  Worse than that, lets remember that WG14 rejected Dennis Ritchie proposal for fat pointers, and the C authors decided it was more fun to keep their own way with other programming languages than try to improve C from WG14. https://www.nokia.com/bell-labs/about/dennis-m-ritchie/vararray.pdf https://www.nokia.com/bell-labs/about/dennis-m-ritchie/varar...
  - abcd_f 8mo ago
    I read through the RFC and I think it's fair it was rejected, because this was ultimately a half-measure, with severe usability restrictions. Fat pointers are clearly a way to deal with arrays (and also get "slices" and non-zero terminated strings for free!), but it's just not possible to retrofit them into the language without breaking existing code.
  - 1718627440 8mo ago
    I think we are talking past each other. I was saying that passing an array with a size to a function was standardized 27 years ago, asking if that isn't long enough. Sure, some may don't like how it was standardized, but it is possible. Beside the sibling comment about this specific proposal, I also think that fat pointers don't belong in the C standard. There is nothing in the C standard that says that pointers on the abstract C machine don't come with the allocated size, in fact the behaviour is described as if they do. Pointers are essentially scoped by allocation. All that is missing is code for that in a C implementation, the language allows that just fine.