    <rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/">
     <channel>
        <title>ACCU  :: Undefined vs. Implementation Defined</title>
        <link>https://members.accu.org/index.php/articles/1065</link>
        <description>Professionalism in Programming</description>
        <dc:language>en-us</dc:language> 
        <dc:creator>Administrator</dc:creator> 
        <admin:generatorAgent rdf:resource="http://www.xaraya.org" /> 
        <admin:errorReportsTo rdf:resource="mailto:webeditor@accu.org" />
       <sy:updatePeriod>hourly</sy:updatePeriod>
       <sy:updateFrequency>1</sy:updateFrequency>
       <docs>http://backend.userland.com/rss</docs>




<div class="xar-mod-head"><span class="xar-mod-title">Programming Topics + CVu Journal Vol 12, #5 - Sep 2000</span></div>

<table border="0" cellpadding="1" cellspacing="0">
    <tbody>
    <tr>
        <td valign="top">
            Browse in :
       </td>
       <td valign="top">

                                            <a href="https://members.accu.org/index.php/articles/">All</a>

                     &gt;                         <a href="https://members.accu.org/index.php/articles/c13/">Topics</a>

                     &gt;                         <a href="https://members.accu.org/index.php/articles/c65/">Programming</a>
<br />

                                            <a href="https://members.accu.org/index.php/articles/">All</a>

                     &gt;                         <a href="https://members.accu.org/index.php/articles/c76/">Journals</a>

                     &gt;                         <a href="https://members.accu.org/index.php/articles/c77/">CVu</a>

                     &gt;                         <a href="https://members.accu.org/index.php/articles/c124/">125</a>
<br />

                                            <a href="https://members.accu.org/index.php/articles/c65-124/">Any of these categories</a>

                    -                        <a href="https://members.accu.org/index.php/articles/c65+124/">All of these categories</a>
<br />
</td>
   </tr>
   </tbody>
</table>




<div class="xar-error">
   <p>
 <strong>Note:</strong> when you create a new publication type,
the articles module will automatically use the templates
<em>user-display-[publicationtype].xt</em>
and <em>user-summary-[publicationtype].xt</em>.
If those templates do not exist when you try to preview or display a new article,
you'll get this warning :-)  Please place your own templates in themes/<em>yourtheme</em>/modules/articles . The templates will get the extension .xt there. </p>
</div>
<div class="xar-norm xar-standard-box-padding">
   <h1><strong>Title:</strong>&nbsp;Undefined vs. Implementation Defined</h1>
<p><strong>Author:</strong>&nbsp;</p>
<p>
<strong>Date:</strong> 03 September 2000 13:15:40 +01:00 or Sun, 03 September 2000 13:15:40 +01:00</p>
<p><strong>Summary:</strong>&nbsp;</p>
<p><strong>Body:</strong>&nbsp;<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e18" id="d0e18"></a></h2>
</div>
<p>In an article, I recently found some code like:</p>
<pre class="programlisting">
  delete this;
  // ...
  this-&gt;other.count-;
</pre>
<p>Of course, it was not so easy to spot, but was hidden in some
function calls, but the effect was the same: the object was used
after deletion. By doing so, the author entered the realm of
undefined behaviour. (Note: <tt class="literal">delete this;</tt>
is not a problem as long as you do not use the object
afterwards.)</p>
<p>The author of the code probably tested it and it worked fine,
and this is exactly the problem of &quot;undefined behaviour&quot;. Undefined
behaviour cannot be tested. It still is undefined.</p>
<p>On the Internet, there are often jokes about undefined behaviour
like: &quot;The program might unplug the computer and shoot it to the
moon.&quot; Of course, you and I, we know that such things do not
happen. The real problem is: if you see something that is undefined
but it behaves the way you want (and you tested it), you still
cannot be sure about this behaviour. While it might run 99 times
correctly (or 9999 times), the next time it might fail. The same
program. The same executable. And if you recompile it, it might do
completely different things.</p>
<p>The recompile point leads us to something that looks similar,
but is in fact completely different: &quot;Implementation defined&quot;.</p>
<p>E.g. <tt class="literal">sizeof(int)</tt> is implementation
defined. You can test it, and if it works the way you expect, it is
guaranteed to work always the same way. You can even recompile it -
as long as you use exactly the same compile options. E.g. the
alignment or padding of <tt class="literal">struct</tt> members is
implementation defined and will probably differ even with the same
compiler, dependent whether you optimise for speed or for size. So
you should better look it up in the documentation of the compiler,
if you use implementation defined behaviour.</p>
<p>So, the bottom line is:</p>
<p><span class="bold"><b>Never use undefined behaviour, even if you
tested it. You can never be sure.</b></span></p>
<p>If you use implementation defined behaviour, your code might not
be portable, not even with the same compiler, but as long as you
follow the documentation of your compiler, you're on the safe
side.</p>
</div>
</p>
<p><strong>Notes:</strong>&nbsp;</p>
<p><em>More fields may be available via dynamicdata ..</em></p>
</div>
</channel>
</rss>
