Conflating pointers with arrays: C's biggest mistake? (2009)
Yes, that&#x27;s C&#x27;s biggest mistake. (But remember, they had to cram the compiler into a 16-bit machine.) No, &quot;fat pointers&quot; are not a backwards-compatible solution. They&#x27;ve been tried. They were a feature of GCC at one time, used by almost nobody.<p>I once had a proposal on this. See [1]. Enough people looked it over to find errors; this is version 3. The consensus is that it would work technically but not politically.<p>The basic idea is that the programmer knows how big the array is; they just don&#x27;t have a way to tell the compiler what expression defines the length of the array. Instead of<p><pre><code>    int read(int fd, char buf[], size_t n);
</code></pre>
you write<p><pre><code>    int read(int n; int fd, char (&amp;buf)[n], size_t n);
</code></pre>
It generates the <i>same calling sequence.</i> Arrays are still passed as plain pointers. But the compiler now knows how big &quot;buf&quot; is, both on the caller and callee side, and can check.<p>I also proposed adding slice syntax to C, so, when you want to talk about part of an array, you do it as a slice, not via pointer arithmetic.<p>The key idea here is that you can call old code from new (&quot;strict&quot;) code, and strict code from old code. When you get to all strict code, subscript errors should be all checkable.<p>[1] <a href="http:&#x2F;&#x2F;www.animats.com&#x2F;papers&#x2F;languages&#x2F;safearraysforc43.pdf" rel="nofollow">http:&#x2F;&#x2F;www.animats.com&#x2F;papers&#x2F;languages&#x2F;safearraysforc43.pdf</a>