Hacker News Reader

Comment by EliRivers | Hacker News Reader

Well, I can see the build command on the webpage there, and assuming this is the same gcc we all know and love without any cleverness going on, it's not a debug build of any kind as far as I can see:

    gcc segfault.c

Now that I think about it, I'm not aware that gcc C compiler even offers the option to deliberately zero initialise non-static local variables, so unless I've missed a switch somewhere there is no arrangement of options available for a "debug build" to do this. I recall the GCC Fortran compiler did offer it.

View on HN

It's the OS linker/loader that zeros the pages used by a new process to avoid leaking memory contents of previous processes (security risk).

It's zero only because this occurs at the very beginning of the program. In general it would be undefined.

Nice. Learn something every day. I edited my original post to add this; save anyone else tracing through the whole thread.

The OS will initialize the memory of the stack to 0 before the program starts. But before main is called, the compiler is free to insert other code that runs before main. gcc inserts a function named __libc_start_main that runs before main. This code will modify the content of the stack. So when main is run, the stack where the uninitialized local variable is has a decent chance of not being 0 anymore.

This is easily testable.

    #include <stdio.h>
    
    int main(void) {
        char* pointers[20];
        int i;
        for (i = 0; i < 20; ++i) {
          printf("%p\n", pointers[i]);
        }
        return 0;
    }

And yes when I run it, most of the pointers are not null.

Sure, the C runtime initialization runs before main. Unless you're looking at the stack at _start, it's probably unintialized. And it depends on your libc implementation, etc.

It just happened to be zero in the author's case.

Oh this is cool! I should have checked more pointers. On my machine, the single pointer was always null, and I read up on stack being initialized to zero. I didn't realize the things-before-main could mess up the stack so much.

I should have made that clearer, thanks! If there were intervening function calls there would be garbage. Then it would only "most likely" segfault instead of always segfault.

Reply on news.ycombinator.com