<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 3, 2014 at 9:31 PM, Ben Laurie <span dir="ltr"><<a href="mailto:ben@links.org" target="_blank">ben@links.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There is the orthogonal question of what to make of this in the face of Purify, valgrind et al. which (almost always rightly) view this entirely harmless practice as evil.<div class="gmail_quote"><div class="gmail_quote"><div><br></div></div></div></blockquote><div><br></div><div><br></div><div>To me this is pretty simple if you think in terms of types.  Yes, sometimes you want to invoke undefined behavior, unusual behavior or poke beneath the common abstractions.  That in itself is not the problem. When you do so, you use an interface so you can inform the compiler, the programmer, the reader, tools like Purify, valgrind etc. about what you are doing.<br><br></div><div>Thus Purify, valgrind etc are correct in flagging this as evil.  They have a more advanced type system in certain cases than what C has.<br></div><div><br></div><div>A programmer or a reader can be informed using a comment, but the other tools typically use functions and types as the way to build interfaces.<br></div><div><br></div><div>Thus reading from uninitialized memory is a two step process.  First you invoke a function that coerces the uninitialized memory into initialized memory.  It could be something like, say  "void *treat_as_initialized(void *)".<br><br></div><div>In the Purify or valgrind type system, this will read as   "void initialized *treat_as_initialized(void *)".  I'm making up the syntax, but this is fundamentally about types and types are what gives assurance, security, and what makes it possible to analyze software.<br><br></div><div>Thinking about it this way makes it obvious that just invoking undefined behavior inside of a function is really bad systems design, both from a theoretical perspective and for maintainance.  Likewise if the software fiddles behind the GC curtain, fiddles with the bytecode interpreter, updates the CPU microcode in the middle of a function etc.  Properties should be expressed as types, and if the language does not support expressing those properties as types, express them as functions / interfaces.<br><br></div><div>Alexander<br></div></div></div></div>