In C it has in many year been the common way to write argument-free functions as fun(). It should however be you go-to naming scheme to write fun(void) instead.

Why? Because the assembly created from the two is actually not identical. In at least x86_64 you will see that fun() actually takes up one more operation = 2bytes more per function.

To explain it, try to look at this perfectly valid piece of C code:

int fun();
int fun(int foobar){
    return 0;
}

This is valid because fun() simply means “no info about the arguments given except that they are not variadic”. Take this in contrast to fun(void) where you tell it that there will be no arguments at all.

Check this example for why it fills more in assembly:

int funA();
int funB(void)
int funC(){
    funA();
    funB();
    return 0;
}

Here you can look at the difference between when funA() and funB() are called. So in the following assembly code check out the line that suddenly precedes the funA() call.

funC:
  pushq %rax        <-- stack realignment for callq
  xorl %eax, %eax   <-- %al is set to zero with eax^eax
  callq funA        <-- call funA
  callq funB        <--- notice that %al was not zeroed this time 
  xorl %eax, %eax   <--- set return to zero
  popq %rcx
  retq

So not setting the args to void means that we need to zero eax before the call of funA every time. xorl %eax, %eax is the generic x86_64 instruction to zero a variable length register. It might not be heavy on the system but in terms micro-optimizations this is a fair point.

So to make sure you use funA(void) next time, remember to use the compiler arguement -Wstrict-prototypes. This will give a warning if you are not clear about your arguments (as in funA() ) and so you will be forced to learn.

Do note that this is only a problem in C and not C++ as C++ actually interprets funA() as “function taking no arguments”.