C Functions Without Arguments

A little known fact about C is that the following two declarations are not considered equivalent by the C compiler:

void hello1() { puts("Hello, world!"); }
void hello2(void) { puts("Hello, world!"); }

The C compiler will consider hello1() to be a variadic function, and will consider hello2() to be a function that takes no arguments.

Now what’s interesting here is that if you don’t use the macros va_start() and va_arg(), the compiler won’t actually generate the code for the two funtions differently. In other words, because hello1() is not actually variadic, and we didn’t put any variadic argument unpacking code into it, the object code for these two will be the same. However, the calling convention is affected.

Looking At Some Object Code

Consider the following program:

#include <stdio.h>

void hello1() { puts("Hello, world!"); }

void hello2(void) { puts("Hello, world!"); }

int main(int argc, char **argv) {
  hello1();
  hello2();
  return 0;
}

I’m going to analyze what happens with gcc -O1, using GCC 5.3.1. (Note: at -O2 and above GCC gets too smart and will just directly embed puts() calls into main(), so that’s why using -O1 is necessary here.)

We get the following in the disassembled output:

0000000000400536 <hello1>:
  400536:       48 83 ec 08             sub    $0x8,%rsp
  40053a:       bf 10 06 40 00          mov    $0x400610,%edi
  40053f:       e8 cc fe ff ff          callq  400410 <puts@plt>
  400544:       48 83 c4 08             add    $0x8,%rsp
  400548:       c3                      retq

0000000000400549 <hello2>:
  400549:       48 83 ec 08             sub    $0x8,%rsp
  40054d:       bf 10 06 40 00          mov    $0x400610,%edi
  400552:       e8 b9 fe ff ff          callq  400410 <puts@plt>
  400557:       48 83 c4 08             add    $0x8,%rsp
  40055b:       c3                      retq

000000000040055c <main>:
  40055c:       48 83 ec 08             sub    $0x8,%rsp
  400560:       b8 00 00 00 00          mov    $0x0,%eax
  400565:       e8 cc ff ff ff          callq  400536 <hello1>
  40056a:       e8 da ff ff ff          callq  400549 <hello2>
  40056f:       b8 00 00 00 00          mov    $0x0,%eax
  400574:       48 83 c4 08             add    $0x8,%rsp
  400578:       c3                      retq
  400579:       0f 1f 80 00 00 00 00    nopl   0x0(%rax)

This isn’t that interesting. As you can see the object code for hello1 and hello2 are exactly identical (other than the immediate argument passed to the relative CALL instruction), since neither is truly variadic nor takes any arguments.

But what if we change the order we call them in? If we change the definition of main() like this:

int main(int argc, char **argv) {
  hello1();
  hello2();
  return 0;
}

Then the generated code for main() will be slightly different. The new code is like this:

000000000040055c <main>:
  40055c:       48 83 ec 08             sub    $0x8,%rsp
  400560:       e8 e4 ff ff ff          callq  400549 <hello2>
  400565:       b8 00 00 00 00          mov    $0x0,%eax
  40056a:       e8 c7 ff ff ff          callq  400536 <hello1>
  40056f:       b8 00 00 00 00          mov    $0x0,%eax
  400574:       48 83 c4 08             add    $0x8,%rsp
  400578:       c3                      retq
  400579:       0f 1f 80 00 00 00 00    nopl   0x0(%rax)

You can see something slightly different. Previously the call looked like:

  400560:       b8 00 00 00 00          mov    $0x0,%eax
  400565:       e8 cc ff ff ff          callq  400536 <hello1>
  40056a:       e8 da ff ff ff          callq  400549 <hello2>

But now it looks like:

  400560:       e8 e4 ff ff ff          callq  400549 <hello2>
  400565:       b8 00 00 00 00          mov    $0x0,%eax
  40056a:       e8 c7 ff ff ff          callq  400536 <hello1>

What’s interesting here is that we can see that %eax is being cleared before the call to hello1(). But it’s not cleared before the call to hello2().

If we remove the call to hello1() altogether, it’s even more obvious what’s happening. Our new main() is

int main(int argc, char **argv) {
  hello2();
  return 0;
}

And the new generated code is:

000000000040055c <main>:
  40055c:       48 83 ec 08             sub    $0x8,%rsp
  400560:       e8 e4 ff ff ff          callq  400549 <hello2>
  400565:       b8 00 00 00 00          mov    $0x0,%eax
  40056a:       48 83 c4 08             add    $0x8,%rsp
  40056e:       c3                      retq
  40056f:       90                      nop

As you can see here %eax is never cleared at all before calling hello2().

The reason this happens is because on x86-64, the calling ABI specifies that %al (i.e. the bottom-most byte of %eax) holds the number of vector registers that are used in the variadic function call. The vector registers are used when you pass variadic arguments in that contain floating point numbers. So even though the generate code for hello1() is exactly the same as the generated code for hello2(), and does not actually inspect the contents of %al, the caller of hello1() must clear the %eax register before calling hello1().

This is an extra instruction that has to happen every time you call a function like this. In practice, the overhead of this is so small that you probably wouldn’t be able to measure it. In fact, modern Intel CPUs can execute multiple integer operations operations in a single clock cycle (as long as there are no register dependencies), so there’s a good chance that in some of these cases there would literally be no overhead. For instance, in the first example we saw the instruction stream

  40055c:       48 83 ec 08             sub    $0x8,%rsp
  400560:       b8 00 00 00 00          mov    $0x0,%eax

A modern Intel CPU will execute both of these instructions simultaneously, in a single clock cycle, since there is no data dependency between %rsp and %eax.

Making a “Variadic” Call

However, what is scarier is that because of this rule if you accidentally pass arguments to hello1() the compiler won’t generate an error or warning, even if you compile with -Wall! For instance, if you compile this program:

#include <stdio.h>

void hello1() { puts("Hello, world!\n"); }

int main(int argc, char **argv) {
  hello1(1);
  return 0;
}

Then gcc -Wall not throw a warning even though this is clearly a mistake. The code generated is interesting in this example:

0000000000400536 <hello1>:
  400536:       48 83 ec 08             sub    $0x8,%rsp
  40053a:       bf 00 06 40 00          mov    $0x400600,%edi
  40053f:       e8 cc fe ff ff          callq  400410 <puts@plt>
  400544:       48 83 c4 08             add    $0x8,%rsp
  400548:       c3                      retq

0000000000400549 <main>:
  400549:       48 83 ec 08             sub    $0x8,%rsp
  40054d:       bf 01 00 00 00          mov    $0x1,%edi
  400552:       b8 00 00 00 00          mov    $0x0,%eax
  400557:       e8 da ff ff ff          callq  400536 <hello1>
  40055c:       b8 00 00 00 00          mov    $0x0,%eax
  400561:       48 83 c4 08             add    $0x8,%rsp
  400565:       c3                      retq
  400566:       66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)
  40056d:       00 00 00

As you can see, the compiler will load 1 into %edi even though hello1() doesn’t actually read that value; in fact, hello1() immediately clobbers %edi with the pointer to the string literal that is passed to puts().

Making a Floating Point Variadic Call

Here’s what happens if we use a vector register, this time by calling it with a floating point number:

#include <stdio.h>

void hello1() { puts("Hello, world!\n"); }

int main(int argc, char **argv) {
  hello1(1.0f);
  return 0;
}

And the generated code is:

0000000000400536 <hello1>:
  400536:       48 83 ec 08             sub    $0x8,%rsp
  40053a:       bf 00 06 40 00          mov    $0x400600,%edi
  40053f:       e8 cc fe ff ff          callq  400410 <puts@plt>
  400544:       48 83 c4 08             add    $0x8,%rsp
  400548:       c3                      retq

0000000000400549 <main>:
  400549:       48 83 ec 08             sub    $0x8,%rsp
  40054d:       f2 0f 10 05 bb 00 00    movsd  0xbb(%rip),%xmm0        # 400610 <__dso_handle+0x18>
  400554:       00
  400555:       b8 01 00 00 00          mov    $0x1,%eax
  40055a:       e8 d7 ff ff ff          callq  400536 <hello1>
  40055f:       b8 00 00 00 00          mov    $0x0,%eax
  400564:       48 83 c4 08             add    $0x8,%rsp
  400568:       c3                      retq
  400569:       0f 1f 80 00 00 00 00    nopl   0x0(%rax)

As you can see, here the literal value 1 is stored into %eax to indicate that the parameter passed in is stored in the vector register %xmm0.

What Makes This Really Weird

This is already kind of strange as it is. But here’s what’s really interesting. You’ll notice that in the example where we invoked hello1(1) that the argument was stored into %edi, but nothing else changed. That’s because in C, when you call a variadic function the calling ABI doesn’t actually tell you how many arguments you got!

So when you make a call like this:

printf("Hello from %d\n", getpid());

The way that printf() knows that it was passed a single argument is by actually scanning the format string for % formatters (%d in this case), and then counting those. This is why if you call printf() with the too few arguments you can can get unexpected things printed to stdout, since you’ll print whatever happens to be in the registers that printf() is looking for that argument in.

In the very uncommon case when you write a variadic function that doesn’t have something like a format string, the convention typically used is that that one of the fixed arguments to the function holds the number of arguments to expect. For instance, you might have a function declared like:

void magic(int num_args, ...);

And then to actually call it you’d have to use an invocation like:

magic(3, 1.0f, "foo", 42);

Then the implementation of magic() will have to use the va_start() and va_arg() macros and know to stop calling va_arg() purely based on inspecting num_arg, since there is literally no other way for magic() to know how many variadic arguments you passed in.

This means that considering a function declaration like:

void magic();

as variadic makes almost no sense. Because there’s no a priori way for the implementation of this version of magic() to know how many variadic arguments it was passed in. In fact, to use the va_start() macro you are required to pass it the last non-variadic argument in the function signature. That means that even if you did come up with a weird protocol for figuring out when va_arg() should stop being called, you’d have to no way to initialize your va_list using the va_start() macro. Really the only way to do this at all would be to write inline assembler in the C function, which wouldn’t make a lot of sense.

C is a rather beautiful language, but it definitely has its warts.