What Every C Programmer Should Know About Undefined Behavior #3/3
What Every C Programmer Should Know About Undefined Behavior #3/3
Posted May 22, 2011 8:57 UTC (Sun) by oak (guest, #2786)Parent article: What Every C Programmer Should Know About Undefined Behavior #3/3
I took a look at those undefined behaviors in the c99 standard specification.
One of the undefined behaviors is: "For a call to a function without a function prototype in scope, the number of arguments does not match the number of parameters".
GCC interprets "name()" as a K&R function name. So, isn't "bar()" in this code:
------ code1.h --------
extern int foo();
------ code1.c --------
#include "code1.h"
int foo() {
return 1;
}
------ code2.c --------
#include "code1.h"
int bar() {
return foo(2);
}
-----------------------
undefined behavior according to the c99 standard and therefore *the whole program* invalid?
Why GCC doesn't give even a warning about this when one uses "-Wall -Wextra -pedantic --std=c99"? [1]
[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48091
The correct ANSI-C prototype for this would be:
------ code1.h --------
extern int foo(void);
-----------------------
But people coding also C++ often think that empty parameter list means void for C like it does for C++. However, GCC (unlike LLVM, MVC etc) assume such declaration is a K&R function instead of a prototype and disables all argument checking for that function, even when one specifically requests pedantic c99 standard checks.
Typically giving extra arguments isn't a problem, but the standard says that without a prototype that's undefined behavior and therefore compiler is in rights to generate in that situation "nasal daemons"...?
Posted May 22, 2011 19:46 UTC (Sun)
by vonbrand (guest, #4458)
[Link]
Functions with and without paramenters can very well be implemented differenty, so this could very well bite you hard one day.
Posted May 23, 2011 5:09 UTC (Mon)
by khim (subscriber, #9252)
[Link]
Yup. That's correct. If your platform uses any form of Callee clean-up by default then your program indeed will blow up (typically it'll generate SIGSEGV but it's not guranteed). Program is still valid if bar() is never called: undefined behavior only makes program invalid when it's actually executed. This is true for any other cases as well. Compiler starts with the set of undefined behaviors and a promise from the programmer: this is program in C (or C++) and that means it does not trigger undefined behavior. How exactly programmer avoids undefined behavior is not important: perhaps there are some math or even command line options. It's not important. The important fact is that program does avoid the undefined behaviors and so all code paths which trigger it can be safely reduced/removed: they can not ever be executed so it's safe. Good compilers have few passes which are dedicated to propagate undefined behavior "back" (if access to some variable always trigger undefined behavior that it's never accessed so there are no need to even calculate it and that means some function calls can often be removed, etc).
What Every C Programmer Should Know About Undefined Behavior #3/3
Yup...
Typically giving extra arguments isn't a problem, but the standard says that without a prototype that's undefined behavior and therefore compiler is in rights to generate in that situation "nasal daemons"...?