Why does a program accessing illegal pointer to pointer not crash?

by

I am not surprised by the lack of a memory fault. The program is not dereferencing an uninitialized pointer. Instead, it is copying and printing the contents of memory beginning at a pointer variable, and the 996 (or 992) bytes beyond it.

Since the pointer is a stack variable, it is printing memory near the top of stack for a ways down. That memory contains the stack frame of main(): possibly some saved register values, a count of program arguments, a pointer to the program arguments, a pointer to a list of environment variables, and a saved instruction register for main() to return, usually in the C runtime library startup code. In all implementations I have investigated, the stack frames below that has copies of the environment variables themselves, an array of pointers to them, and an array of pointers to the program arguments. In Unix environments (which you hint you are using) the program argument strings will be below that.

All of this memory is “safe” to print, except some non-printable characters will appear which might mess up a display terminal.

The chief potential problem is whether there is enough stack memory allocated and mapped to prevent a SIGSEGV during access. A segment fault could happen if there is too little environment data. Or if the implementation puts that data elsewhere so that there are only a few words of stack here. I suggest confirming that by cleaning out the environment variables and re-running the program.

This code would not be so harmless if any of the C runtime conventions are not true:

  • The architecture uses a stack
  • A local variable (void *x) is allocated on the stack
  • The stack grows toward lower numbered memory
  • Parameters are passed on the stack
  • Whether main() is called with arguments. (Some light duty environments, like embedded processors, invoke main() without parameters.)

In all mainstream modern implementations, all of these are generally true.

More Related Contents:

  1. function returns address of local variable, but it still compile in c, why?
  2. Given the state of the stack and registers, can we predict the outcome of printf’s undefined behavior
  3. Why are these constructs using pre and post-increment undefined behavior?
  4. (Why) is using an uninitialized variable undefined behavior?
  5. Can we change the value of an object defined with const through pointers?
  6. Is the “struct hack” technically undefined behavior?
  7. Is a^a or a-a undefined behaviour if a is not initialized?
  8. Is accessing a global array outside its bound undefined behavior?
  9. How undefined is undefined behavior?
  10. Is the behaviour of casting a negative double to unsigned int defined in the C standard? Different behaviour on ARM vs. x86
  11. A question about union in C – store as one type and read as another – is it implementation defined?
  12. When is casting between pointer types not undefined behavior in C?
  13. Is the output of printf (“%d %d”, c++, c); also undefined?
  14. What is Undefined Behaviour in C? [duplicate]
  15. In C99, is f()+g() undefined or merely unspecified?
  16. Unspecified, undefined and implementation defined behavior WIKI for C
  17. How to implement memmove in standard C without an intermediate copy?
  18. Is this undefined C behaviour?
  19. C – function returning a pointer to a local variable
  20. Is while(1); undefined behavior in C?
  21. Does C have an equivalent of std::less from C++?
  22. Order of evaluation of arguments in function calling?
  23. C code with undefined results, compiler generates invalid code (with -O3)
  24. printf() with no arguments in C compiles fine. how?
  25. C – is an indeterminate value indeterminable?
  26. Does ctype.h still require unsigned char?
  27. Why is undefined behaviour allowed in C
  28. Turbo C++: Why does printf print expected values, when no variables are passed to it?
  29. 2D Array indexing – undefined behavior?
  30. Uninitialized variable in C [duplicate]

Leave a Comment