当我在C语言中忽略函数的参数时会发生什么？

Question

First of all, I know this way of programming is not good practice. For an explanation of why I'm doing this, read on after the actual question.

When declaring a function in C like this:

int f(n, r) {…}

The types of r and n will default to int . The compiler will likely generate a warning about it, but let's choose to ignore that.

Now suppose we call f but, accidentally or otherwise, leave out an argument:

f(25);

This will still compile just fine (tested with both gcc and clang). However there is no warning from gcc about the missing argument.

So my question is:

1. Why does this not produce a warning (in gcc) or error?
2. What exactly happens when it is executed? I assume I'm invoking undefined behaviour but I'd still appreciate an explanation.

Note that it does not work the same way when I declare int f(int n, int r) {…} , neither gcc nor clang will compile this .

Now if you're wondering why I would do such a thing, I was playing Code Golf and tried to shorten my code which used a recursive function f(n, r) . I needed a way to call f(n, 0) implicitly, so I defined F(n) { return f(n, 0) } which was a little too many bytes for my taste. So I wondered whether I could just omit this parameter. I can't, it still compiles but no longer works.

While optimizing this code, it was pointed out to me that I could just leave out a return at the end of my function – no warning from gcc about this either. Is gcc just too tolerant?

Answer 1

1. You don't get any diagnostics from the compiler because you are not using modern "prototyped" function declarations. If you had written

    int f(int n, int r) {…} 

   then a subsequent f(25) would have triggered a diagnostic. With the compiler on the computer I'm typing this on, it's actually a hard error.

   "Old-style" function declarations and definitions intentionally cause the compiler to relax many of its rules, because the old-style code that they exist for backward compatibility with would do things like this all the dang time. Not the thing you were trying to do, hoping that f(25) would somehow be interpreted as f(25, 0) , but, for instance, f(25) where the body of f never looks at the r argument when its n argument is 25.

2. The pedants commenting on your question are pedantically correct when they say that literally anything could happen (within the physical capabilities of the computer, anyway; "demons will fly out of your nose" is the canonical joke, but it is, in fact, a joke). However, it is possible to describe two general classes of things that are what usually happens.

   With older compilers, what usually happens is, code is generated for f(25) just as it would have been if f only took one argument. That means the memory or register location where f will look for its second argument is uninitialized, and contains some garbage value.

   With newer compilers, on the other hand, the compiler is liable to observe that any control-flow path passing through f(25) has undefined behavior, and based on that observation, assume that all such control-flow paths are never taken , and delete them. Yes, even if it's the only control-flow path in the program. I have actually witnessed Clang spit out main: ret for a program all of whose control-flow paths had undefined behavior!

3. GCC not complaining about f(n, r) { /* no return statement */ } is another case like (1), where the old-style function definition relaxes a rule. void was invented in the 1989 C standard; prior to that, there was no way to say explicitly that a function does not return a value. So you don't get a diagnostic because the compiler has no way of knowing that you didn't mean to do that.

   Independently of that, yes, GCC's default behavior is awfully permissive by modern standards. That's because GCC itself is older than the 1989 C standard and nobody has reexamined its default behavior in a long time. For new programs, you should always use -Wall , and I recommend also at least trying -Wextra , -Wpedantic , -Wstrict-prototypes , and -Wwrite-strings . In fact, I recommend going through the "Warning Options" section of the manual and experimenting with all of the additional warning options. (Note however that you should not use -std=c11 , because that has a nasty tendency to break the system headers. Use -std=gnu11 instead.)

Answer 2

First off, the C standard doesn't distinguish between warnings and errors. It only talks about "diagnostics". In particular, a compiler can always produce an executable (even if the source code is completely broken) without violating the standard. ¹

The types of r and n will default to int .

Not anymore. Implicit int has been gone from C since 1999. (And your test code requires C99 because for (int i = 0; ... isn't valid in C90).

In your test code gcc does issue a diagnostic for this:

.code.tio.c: In function ‘f’:
.code.tio.c:2:5: warning: type of ‘n’ defaults to ‘int’ [-Wimplicit-int]

It's not valid code, but gcc still produces an executable (unless you enable -Werror ).

If you add the required types ( int f(int n, int r) ), it uncovers the next issue:

.code.tio.c: In function ‘main’:
.code.tio.c:5:3: error: too few arguments to function ‘f’

Here gcc somewhat arbitrarily decided not to produce an executable.

Relevant quotes from C99 (and probably C11 too; this text hasn't changed in the n1570 draft ):

6.9.1 Function definitions

Constraints

[...]

6. If the declarator includes an identifier list, each declaration in the declaration list shall have at least one declarator, those declarators shall declare only identifiers from the identifier list, and every identifier in the identifier list shall be declared.

Your code violates a constraint (your function declarator includes an identifier list, but there is no declaration list), which requires a diagnostic (such as the warning from gcc).

Semantics

7. [...] If the declarator includes an identifier list, the types of the parameters shall be declared in a following declaration list.

Your code violates this shall rule, so it has undefined behavior. This applies even if the function is never called!

6.5.2.2 Function calls

Constraints

[...]

2. If the expression that denotes the called function has a type that includes a prototype, the number of arguments shall agree with the number of parameters. [...]

Semantics

[...]

6. [...] If the number of arguments does not equal the number of parameters, the behavior is undefined. [...]

The actual call also has undefined behavior if the number of arguments passed doesn't match the number of parameters the function has.

As for omitting return : This is actually valid as long as the caller doesn't look at the returned value.

Reference (6.9.1 Function definitions, Semantics):

12. If the } that terminates a function is reached, and the value of the function call is used by the caller, the behavior is undefined.

---

¹ The sole exception seems to be the #error directive, about which the standard says:

The implementation shall not successfully translate a preprocessing translation unit containing a #error preprocessing directive unless it is part of a group skipped by conditional inclusion.