An extern C pointer puzzler

Question

You are given the following two C files:

#include <stdint.h>
#include <stdio.h>

extern uint32_t *foo;

int main() {
    printf("%p\n", foo);
    printf("%x\n", *foo);
}

and

#include <stdint.h>
uint32_t foo[2] = {0xDEADBEEF, 0xCAFEFEED};

Assuming you're running on an x86_64 processor, what happens when you compile and link these two files together? More importantly, why?

Answer 1

There is separate "stack" site for puzzlers: https://codegolf.stackexchange.com/

In your case you are lying to your compiler. You define 'foo' as name for an array in second file and as a pointer in you 'main' file. array and pointer are different concepts.

If you change extern declaraion in main to be the same as in second module you will be ok: extern uint32_t foo[];

Added: If you "inline" foo and replace extern uint32_t *foo; with uint32_t foo[2] = {0xDEADBEEF, 0xCAFEFEED}; Then compiler will see that your variable is not a pointer but rather a name for an array. Exactly like when you do extern unit32_t foo[]. Check, for example, here: Is an array name a pointer?.

Answer 2

You will get

DEADBEEFCAFEFEED
Segmentation fault

?

Because C arrays are stored directly, there is no such thing as intermediate reference or pointer to them. I think you'd expect that to happen:

1. C compiler puts two DEAD numbers somethere (consumes 8 bytes).
2. C compiler creates a pointer to that memory area and calls it foo (consumes additional 8 bytes).
3. Linker uses that pointer foo later in main file

Step 2 is easy to expect because in many cases arrays act like they are pointers, i.e.:

int a[2] = {1, 3};
...
*a

But they are not pointers, its just C compiler knows what you mean by saying *a. You can check it by taking reference:

int a[2] = {1, 2};  
printf("%p %p\n", a, &a);  /* Prints same values */

So here are whats really happens:

1. C compiler puts two DEAD numbers somethere and calls them foo
2. Linker uses that pointer foo later in main file. But linker do not know if foo was an array, so it treats it like traditional 8 byte pointer.

Answer 3

As the other answer pointed out, you lied to the compiler about the type of foo. Hence your program has undefined behavior, which in this case results in a segmentation fault.

When declaring an variable as extern, you should never put the extern statement into the .c file directly. You should always put the extern statement into a header file and then #include that header in any .c file that needs it. But most importantly, you should always include that header in the .c file that defines the variable, so that the compiler can verify the extern declaration against the variable definition.

So the code should have consisted of the three files shown below

foo.h

#include <stdint.h>
extern uint32_t *foo;

foo.c

#include <stdint.h>
#include "foo.h"
uint32_t foo[2] = {0xDEADBEEF, 0xCAFEFEED};

main.c

#include <stdio.h>
#include <stdint.h>
#include "foo.h"

int main( void )
{
    printf("%p\n", (void *)foo);
    printf("%x\n", *foo);
}

In that case, the error messages that you get from gcc are

foo.c:3: error: conflicting types for ‘foo’

foo.h:2: error: previous declaration of ‘foo’ was here

And, of course, you need to fix the error by fixing foo.h

foo.h

#include <stdint.h>
extern uint32_t foo[];