Will address of `foo' here be always non-zero? - c

Question

I have the following code:
#include <stdio.h>
#include <stdlib.h>
extern void foo(double);
int main(void) {
// printf("address is: %p\n", *foo);
if (foo)
puts("indeed");
else
puts("not");
exit(0);
}
It always compiles and prints indeed if line number 7 is commented but gcc warns me that:
the address of 'foo' will always evaluate as 'true' [-Waddress]
However, it doesn't compile if line 7 is uncommented:
/tmp/ccWvhcze.o: In function `main':
post.c:(.text.startup+0x5): undefined reference to `foo'
collect2: error: ld returned 1 exit status
Well, if address is always non-zero according to gcc why does linking fail? Of course, I would expect it because foo is just not defined here but why does gcc claim that address will always be non-zero? Is it mandated by C standard for all identifiers in the translation unit to always evaluate to true?

Answer 1

Testing if (pointer_expression) checks whether the pointer is a null pointer or not. Every valid object and function is guaranteed to not be a null pointer. (Note that a null pointer is not necessarily "zero".)

Answer 2

The compiler removes the test in if () because it's guaranteed to be true. Because of that the linker has nothing to resolve. Adding a printf of foo adds back the need to resolve foo.

Answer 3

You must remember that compilation and linking are two completely separate and independent phases for C programs. The compiler is saying "if (and only if) you link and execute this code, foo will always be non-zero". However, you then go on to attempt to link that object file into an executable without supplying a definition for foo (only a declaration). That's illegal, so linking fails. foo isn't NULL or not-NULL, it doesn't have a value.

Answer 4

Not tested because I'm writing this from my smartphone, I guess foo may become zero.
For example, linking with this NASM code will make foo zero if my thought is correct.
bits 32
absolute 0
global foo
global _foo
foo:
_foo:
UPDATE:
I tested this code with GCC 4.8.1 and NASM 2.11.08 and got output
address is: 00000000
indeed
Also, although this code is differ from the original, this code for xv6 on Ubuntu, GCC 4.6.3 ran on Vagrant VM
#include "types.h"
#include "user.h"
void foo(double a) {
(void)a;
}
int main(void) {
printf(1, "address is : %p\n", (void*)*foo);
if (foo)
printf(1, "indeed\n");
else
printf(1, "not\n");
exit();
}
emitted output
address is : 0
indeed
(remove -Werror from the CFLAGS in xv6 Makefile, or you will get a compile error)
Also note that *foo becomes address of function foo because foo as operand of operator * is converted to a pointer to function foo, then dereferenced with * and becomes function foo, then converted to a pointer again for function parameter.

Answer 5

As others have pointed out the GCC assumes 'foo' will never be zero. If you have function 'foo' then it will have some address, if function foo is not defined then your program simply will not link and there will be no executable to run. If you are linking to 'dll' or 'so' file that had function 'foo' at the time of linking, but later at the time of execution it was removed then your executable will not load. So GCC safely assumes that 'foo' will never be zero.
However, it is correct in 99.(99)% of the cases. As MikeCat pointed out the function foo could be located at address zero. This will never happen for user space executable or even the kernel code does not resort to such tricks. The only practical programs that do play with putting objects at absolute addresses are boot loaders and other things that run directly on the hardware.
They rely on linker scripts to place objects at correct addresses. Here is an example of code that does it technically yes, but this is very sick thing to do. The only C program I know that needs to resort to such tricks is boot loader code https://github.com/trini/u-boot/blob/master/arch/arm/mach-at91/armv7/u-boot-spl.lds
But, even if boot loaders can do such thing, GCC still might be correct. Most of the CPUs or OSes reserve address '0' for some special purposes. Most of the time the interrupt vector table is located there, in other cases OS or Architecture itself reserves address 0 for null pointer so any attempt to access it will result in exception. I believe x86 protected mode, which is the mode in which all popular OSes (Linux, Windows) run user programs, is one of such architectures.
So GCC in your case GCC is probably correct at optimizing away the if statement, because you are using x86 version of gcc. If you ever find the architecture where address 0 is not reserved, it will most likely have a version of GCC that does not perform this type of optimization.