Pointers Are Complicated, or What’s in a Byte?
The idea of redefining pointers from an {address} to an {offset,allocation_id} tuple seems to me a very powerful solution to the problems discussed recently in <i>&quot;C&#x27;s biggest mistake: conflating pointers with arrays&quot;</i> [1]<p>Instead of redefining arrays and introduce a new incompatible syntax, we are redefining the compiler representation of what a pointer is and get run-time guarantees of correctness without modifying the source code of existing C and C++ programs. For example, on a 64 bit machine a pointer can become an 128 bit long concatenation of two address:<p><pre><code>  [ptr][alloc_id]
</code></pre>
The [ptr] part is binary equivalent of existing C pointers (the memory address of the pointed object), while the alloc_id is another 64 bit address of the allocation structure from which the object is part of. Here is a &quot;fat&quot; pointer that indexes the 4th element of an array, previously allocated by malloc(8 * sizeof(object)) :<p><pre><code>  [ ][ ][ ][ ][ ][ ][ ][ ][malloc_data]
           ^______     ___^
                 |    |
               [ptr][alloc_id]   = &quot;fat pointer&quot;

</code></pre>
Defining the allocation_ID as the address of the malloc data structure and placing that at the end of the array earns us a very efficient way to make sure pointer increment (a very frequent operation and source of memory bugs) still points inside of the array, in a single assembly instruction: just CMP the new [ptr] with the [alloc_id] 
(for other operations, like pointer arithmetic with negative ints where [ptr] can go down, you would of course need to deference [alloc_id] and obtain the lower limit of the array stored somewhere in the malloc_data structure)<p>This solves a slew of problems:<p>- pointer arithmetic can now be performed only when it makes sense (identical alloc_id)<p>- binary equality of pointers is a guarantee that they point to the same object<p>- the compiler can easily implement some or more memory protection checks, based on the desired performance-safety trade-off<p>- the cost in memory or stack space of doubling pointer size should not have a significant impact on most real programs<p>- no syntax changes should be required<p>Since this cannot be a new ideea, I would like someone more knowledgeable to poke some holes in it.<p>[1] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17585357" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17585357</a>