4 ms·

edit: exDM69 actually makes more sense.

by dkopi 10y ago

EliRivers 10y ago
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.
- exDM69 10y ago
  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.
  - EliRivers 10y ago
    Nice. Learn something every day. I edited my original post to add this; save anyone else tracing through the whole thread.
  - Buge 10y ago
    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.
    - exDM69 10y ago
      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.
    - kalmar 10y ago
      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.
  - kalmar 10y ago
    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.

edit: exDM69 actually makes more sense.

by dkopi 10y ago

edit: exDM69 actually makes more sense.

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.

exDM69 10y ago
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.
- EliRivers 10y ago
  Nice. Learn something every day. I edited my original post to add this; save anyone else tracing through the whole thread.
- Buge 10y ago
  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.
  - exDM69 10y ago
    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.
  - kalmar 10y ago
    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.
- kalmar 10y ago
  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.