<p>I believe one used to be able to do this in C:</p>
<pre class="lang-c prettyprint-override"><code>int main(void) {
    return printf(&quot;Hello world!&quot;) &gt; 0;
}
</code></pre>
<p>Now this became invalid in C99, and one must do this:</p>
<pre class="lang-c prettyprint-override"><code>#include &lt;stdio.h&gt; // int printf(const char *restrict, ...);
int main(void) {
    return printf(&quot;Hello world!&quot;) &gt; 0;
}
</code></pre>
<p>What are/were the perceived problems with supporting implicit declaration of functions in code?</p>

<functions><declarations>
Why is implicitly declaring functions problematic?
<p>To compile a call to a function, it is crucial to know its signature precisely. If it is left to be inferred from the argument types, it allows for hard-to-trace mistakes (like wrong argument order, or assumed implicit casts not taking place)</p>

CC BY-SA 4.0
2023-06-07T18:38:34.733Z
2023-06-07T18:38:34.733Z
abel1502
<h1>Typos</h1>
<p>Consider this code:</p>
<pre class="lang-c prettyprint-override"><code>int main(void) {
  return pritnf(&quot;Hello, World!\n&quot;) &gt; 0;
}
</code></pre>
<p>This file would compile, and only fail at link-time when <code>pritnf</code> can’t be found. Speaking from experience, linker errors are a lot harder to diagnose than compiler errors, since they don’t point to a location in the original source code.</p>

CC BY-SA 4.0
2023-06-07T18:12:53.280Z
2023-06-07T18:12:53.280Z
Bbrk24
<p>There may be a design space where implicit function declarations are desirable, such as when synthesising functions from structural effect handlers or struct fields, however C's approach is problematic for a simple reason: it assumes an unknown function to be of type <code>int()</code> and to be <code>extern</code>.<br />
This means it works with <code>printf</code>, but not with <code>malloc</code>, nor <code>atof</code>.<br />
It did make <em>some</em> sense for such a feature to exist in early C, as almost all routines from its stdlib returned either <code>void</code> or <code>int</code>, and as <code>()</code> makes a function variadic, however, for C99 the Committee decided to remove implicit declarations, justifying its action as so:</p>
<blockquote>
<p>25 A new feature of C99: The rule for implicit declaration of functions has been removed in C99.
The effect is to guarantee the production of a diagnostic that will catch an additional category of
programming errors. After issuing the diagnostic, an implementation may choose to assume an
implicit declaration and continue translation in order to support existing programs that exploited
this feature.</p>
</blockquote>
<ul>
<li><a href="https://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf" rel="noreferrer">Rationale for International Standard Programming Languages C Revision 5.10 April-2003§6.5.2.2</a></li>
</ul>

CC BY-SA 4.0
2023-06-07T22:57:42.610Z
2023-06-09T15:46:57.723Z
2023-06-09T15:46:57.723Z
Longinus
# Why is implicitly declaring functions problematic?
Posted by: username_0 on 2023-06-07
I believe one used to be able to do this in C:
int main(void) {
    return printf("Hello world!") > 0;
}

Now this became invalid in C99, and one must do this:
#include  // int printf(const char *restrict, ...);
int main(void) {
    return printf("Hello world!") > 0;
}

What are/were the perceived problems with supporting implicit declaration of functions in code?
**Tags:** functions declarations
---
## 3 answers
### Answer by username_3 on 2023-06-07. Score: 9 | Accepted answer
There may be a design space where implicit function declarations are desirable, such as when synthesising functions from structural effect handlers or struct fields, however C's approach is problematic for a simple reason: it assumes an unknown function to be of type `int()` and to be `extern`.  
This means it works with `printf`, but not with `malloc`, nor `atof`.  
It did make *some* sense for such a feature to exist in early C, as almost all routines from its stdlib returned either `void` or `int`, and as `()` makes a function variadic, however, for C99 the Committee decided to remove implicit declarations, justifying its action as so:

> 25 A new feature of C99: The rule for implicit declaration of functions has been removed in C99.
> The effect is to guarantee the production of a diagnostic that will catch an additional category of
> programming errors. After issuing the diagnostic, an implementation may choose to assume an
> implicit declaration and continue translation in order to support existing programs that exploited
> this feature.

* [Rationale for International Standard Programming Languages C Revision 5.10 April-2003§6.5.2.2](https://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf)
---
### Answer by username_2 on 2023-06-07. Score: 7
Typos
Consider this code:
int main(void) {
  return pritnf("Hello, World!\n") > 0;
}

This file would compile, and only fail at link-time when pritnf can’t be found. Speaking from experience, linker errors are a lot harder to diagnose than compiler errors, since they don’t point to a location in the original source code.
---
### Answer by username_1 on 2023-06-07. Score: 5
To compile a call to a function, it is crucial to know its signature precisely. If it is left to be inferred from the argument types, it allows for hard-to-trace mistakes (like wrong argument order, or assumed implicit casts not taking place)
---
