<story><title>Deep C (2011)</title><url>http://www.pvv.org/~oma/DeepC_slides_oct2011.pdf</url></story><parent_chain></parent_chain><comment><author>GlitchMr</author><text>All the talk about `printf(&amp;quot;%d\n&amp;quot;, a);` and it&amp;#x27;s invalid due to a certain part of a language. From list of undefined behaviours (J.2).&lt;p&gt;&amp;gt; In a context requiring two function types to be compatible, they do not have compatible return types, or their parameters disagree in use of the ellipsis terminator or the number and type of parameters (after default argument promotion, when there is no parameter type list or when one type is speciﬁed by a function deﬁnition with an identiﬁer list) (6.7.5.3).&lt;p&gt;&amp;gt; disagree in use of the ellipsis terminator&lt;p&gt;printf is called with the following implicit type signature (due to not including stdio.h)&lt;p&gt;&lt;pre&gt;&lt;code&gt;    int (char *, int);
&lt;/code&gt;&lt;/pre&gt;
However, the actual printf signature is as follows.&lt;p&gt;&lt;pre&gt;&lt;code&gt;    int (const char *, ...);
&lt;/code&gt;&lt;/pre&gt;
While char * can be used where const char * is being used, int is not a valid replacement for ellipsis terminator. As such, the correct answer is that it&amp;#x27;s undefined behaviour.&lt;p&gt;(of course, most implementations will allow this code, but strictly speaking as a language lawyer it is undefined behaviour)</text></comment>
<story><title>Deep C (2011)</title><url>http://www.pvv.org/~oma/DeepC_slides_oct2011.pdf</url></story><parent_chain></parent_chain><comment><author>madhadron</author><text>I know most of this trivia except where it crossed to C++, which I don&amp;#x27;t pretend to understand. And instead of a candidate having a deep knowledge of this, I would rather have the compiler refuse to compile most of the examples. Computers are good at repetitively checking things. Why should I have to?</text></comment>