<story><title>Handles Are the Better Pointers (2018)</title><url>https://floooh.github.com/2018/06/17/handles-vs-pointers.html</url></story><parent_chain><item><author>anilakar</author><text>Moving away from pointers and using a shared pool of handles with integer indexes will introduce a whole new array of issues. A plain int carries no information about the validity of the object behind that handle because they are carried around as copies, not references.&lt;p&gt;I remember debugging a regression with UNIX network sockets where valid connections were being killed, and the bug was only triggered under heavy load. Deadlines were approaching and as a desperate measure I did the exact opposite the article suggests: I wrapped all the socket calls to only accept pointers to an opaque struct with a single integer and made sure the int was set to a guardian value to indicate invalidation after an error. The culprit was a double-close that normal debugging tools such as Valgrind could not find but my unorthodox refactoring did.&lt;p&gt;Later I&amp;#x27;ve learnt to love UUID&amp;#x27;s whenever performance allows. They&amp;#x27;re not pointers so they don&amp;#x27;t introduce memory handling issues and they can be easily tracked in e.g. distributed data pipelines and logging systems.</text></item></parent_chain><comment><author>AnIdiotOnTheNet</author><text>&amp;gt; A plain int carries no information about the validity of the object behind that handle because they are carried around as copies, not references.&lt;p&gt;A pointer is just an integer index to a byte in memory in most computing architectures.</text></comment>
<story><title>Handles Are the Better Pointers (2018)</title><url>https://floooh.github.com/2018/06/17/handles-vs-pointers.html</url></story><parent_chain><item><author>anilakar</author><text>Moving away from pointers and using a shared pool of handles with integer indexes will introduce a whole new array of issues. A plain int carries no information about the validity of the object behind that handle because they are carried around as copies, not references.&lt;p&gt;I remember debugging a regression with UNIX network sockets where valid connections were being killed, and the bug was only triggered under heavy load. Deadlines were approaching and as a desperate measure I did the exact opposite the article suggests: I wrapped all the socket calls to only accept pointers to an opaque struct with a single integer and made sure the int was set to a guardian value to indicate invalidation after an error. The culprit was a double-close that normal debugging tools such as Valgrind could not find but my unorthodox refactoring did.&lt;p&gt;Later I&amp;#x27;ve learnt to love UUID&amp;#x27;s whenever performance allows. They&amp;#x27;re not pointers so they don&amp;#x27;t introduce memory handling issues and they can be easily tracked in e.g. distributed data pipelines and logging systems.</text></item></parent_chain><comment><author>bluetomcat</author><text>&amp;gt; A plain int carries no information about the validity of the object behind that handle because they are carried around as copies, not references.&lt;p&gt;The article suggests a handle containing a &amp;quot;plain int&amp;quot; plus a &amp;quot;unique bit pattern&amp;quot;, the latter acting like a watermark which is compared to the one in the private array of the corresponding module, preventing dangling accesses.&lt;p&gt;Apart from rare occasional collisions in the bit pattern causing a false negative on a dangling access, what other issues can be found with this approach?</text></comment>