StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>More terminology (C, not C++): a prototype for a function declares the types of its arguments. Otherwise the function does not have a prototype.</p> <pre><code>void f(); // Declaration, but not a prototype void f(void); // Declaration and prototype void f(int a, int b, float c); // Declaration and prototype </code></pre> <p>Declarations that aren't prototypes are holdovers from pre-ANSI C, from the days of K&R C. The only reason to use an old-style declaration is to maintain binary compatibility with old code. For example, in Gtk 2 there is a function declaration without a prototype -- it is there by accident, but it can't be removed without breaking binaries. The C99 standard comments:</p> <blockquote> <p>6.11.6 Function declarators</p> <p>The use of function declarators with empty parentheses (not prototype-format parameter type declarators) is an obsolescent feature.</p> </blockquote> <p><strong>Recommendation:</strong> I suggest compiling all C code in GCC/Clang with <code>-Wstrict-prototypes</code> and <code>-Wmissing-prototypes</code>, in addition to the usual <code>-Wall -Wextra</code>.</p> <h2>What happens</h2> <pre><code>void f(); // declaration void f(int a, int b, float c) { } // ERROR </code></pre> <p>The declaration disagrees with the function body! This is actually a <em>compile time</em> error, and it's because you can't have a <code>float</code> argument in a function without a prototype. The reason you can't use a <code>float</code> in an unprototyped function is because when you call such a function, all of the arguments get promoted using certain default promotions. Here's a fixed example:</p> <pre><code>void f(); void g() { char a; int b; float c; f(a, b, c); } </code></pre> <p>In this program, <code>a</code> is promoted to <code>int</code><sup>1</sup> and <code>c</code> is promoted to <code>double</code>. So the definition for <code>f()</code> has to be:</p> <pre><code>void f(int a, int b, double c) { ... } </code></pre> <p>See C99 6.7.6 paragraph 15,</p> <blockquote> <p>If one type has a parameter type list and the other type is specified by a function declarator that is not part of a function definition and that contains an empty identifier list, the parameter list shall not have an ellipsis terminator and the type of each parameter shall be compatible with the type that results from the application of the default argument promotions.</p> </blockquote> <h2>Answer 1</h2> <blockquote> <p>What happens at compile time in cases 1 and 2 when we call <code>f</code> with the correct arguments, wrong arguments and no arguments at all? What happens at run time?</p> </blockquote> <p>When you call <code>f()</code>, the parameters get promoted using the default promotions. If the promoted types match the actual parameter types for <code>f()</code>, then all is good. If they don't match, it will <em>probably</em> compile but you will definitely get undefined behavior.</p> <p>"Undefined behavior" is spec-speak for "we make no guarantees about what will happen." Maybe your program will crash, maybe it will work fine, maybe it will invite your in-laws over for dinner.</p> <p>There are two ways to get diagnostics at compile-time. If you have a sophisticated compiler with cross-module static analysis capabilities, then you will probably get an error message. You can also get messages for un-prototyped function declarations with GCC, using <code>-Wstrict-prototypes</code> -- which I recommend turning on in all your projects (except for files which use Gtk 2).</p> <h2>Answer 2</h2> <blockquote> <p>If I declare <code>f</code> with arguments, but define it without them, will it make a difference? Should I be able to address the arguments from the function body?</p> </blockquote> <p>It shouldn't compile.</p> <h2>Exceptions</h2> <p>There are actually two cases in which function arguments are allowed to disagree with the function definition.</p> <ol> <li><p>It is okay to pass <code>char *</code> to a function that expects <code>void *</code>, and vice versa.</p></li> <li><p>It is okay to pass a signed integer type to a function that expects the unsigned version of that type, or vice versa, as long as the value is representable in both types (i.e., it is not negative, and not out of range of the signed type).</p></li> </ol> <h2>Footnotes</h2> <p><sup>1</sup>: It is <em>possible</em> that <code>char</code> promotes to <code>unsigned int</code>, but this is very uncommon.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload