Any decent C compiler has a warning for the situation that an external function is called without a prototype declaration having been seen.
GCC also has diagnostics for when a function definition occurs without a declaration.
From GCC man page:
-Wmissing-prototypes (C and Objective-C only)
Warn if a global function is defined without a previous prototype
declaration. This warning is issued even if the definition itself
provides a prototype. The aim is to detect global functions that
fail to be declared in header files.
-Wstrict-prototypes (C and Objective-C only)
Warn if a function is declared or defined without specifying the
argument types. (An old-style function definition is permitted
without a warning if preceded by a declaration which specifies the
argument types.)
-Wimplicit-function-declaration (C and Objective-C only)
Give a warning whenever a function is used before being declared.
In C99 mode (-std=c99 or -std=gnu99), this warning is enabled by
default and it is made into an error by -pedantic-errors. This
warning is also enabled by -Wall.
Re:Function overloading in C
by danieltillett on Sunday July 26, 2015 @07:23PM
(#9952588)
If you turn on wall you should be warned that you didn’t include the right headers?
I was under the impression that lots of implementations of malloc actually call calloc under the hood. Unless you are calling malloc in a tight loop I can’t see the extra step of zeroing being a issue. In one of my programs where performance is critical I changed over all my mallocs to calloc and couldn’t measure the time change - I did find I had fewer difficult-to-duplicate bugs though.
Edit. Interestingly CERT recommends casting [1]. Seems to solve a much worse issue than forgetting to include stdlib.h
1. https://www.securecoding.cert.org/confluence/display/c/MEM02...
But more stylistically, let's be honest, something like this is way too verbose:
I see code like this often, and I think the only explanation I can think of is that people don't know the language well enough to write: > A related question is why do people use malloc if calloc is available?Seems like a very different question... calloc multiplies, calls malloc, and zeros. I guess if you don't want to multiply, don't want to zero, don't want to bother specifying another parameter, some combination of these, then malloc might be a better choice. Though I do recall a few years back the OpenBSD folks (possibly others too?) focusing on making sure calloc checks for overflow when it multiplies. [See also: reallocarray]