0

Coming from Visual Studio/MSVC, I'm expecting that accessing an uninitialized pointer will result in an Access Violation/segfault for Debug builds at least.

This is because Visual Studio fills all uninitialized memory with magic numbers like 0xcdcdcdcd and the like, and it has protected 0xcdcdcdcd so attempting to read/write from it will generate an Access Violation.

But to my surprise, GCC on Linux does no such thing, so accessing uninitialized pointers can cause memory corruption even in Debug builds, which can be very hard to debug.

This test code will happily access the memory location in my test app when compiled using GCC:

int *p;
int n = *p;

I am using Qt Creator as my IDE, and I'm compiling a Debug build:

gcc -c -pipe -g -Wall -W -fPIE  -I../untitled19 -I. -I/opt/Qt/5.4/gcc/mkspecs/linux-g++ -o main.o ../untitled19/main.c
g++ -Wl,-rpath,/opt/Qt/5.4/gcc -o untitled19 main.o

Why does GCC lack such an important feature by default, and hopefully, is there a compiler flag that would enable it?

I've found Magic numbers when debugging with gcc/g++/gdb/valgrind?, but the answers there are very unsatisfactory and basically suggest that you should write your own new/delete implementations, which doesn't even cover uninitialized pointers that are local variables.

sashoalm
  • 75,001
  • 122
  • 434
  • 781
  • Does MSVC provide an access violation for that example? –  Oct 08 '16 at 18:08
  • I'm using MinGW GCC 6.2.0 with Qt Creator 5.6 on Windows, and reading from such pointer is fine, but using the value causes segfault. – xinaiz Oct 08 '16 at 18:11
  • @DieterLücking Yes, but in a Debug build only. It's a very useful feature and ensures that you never have memory corruption from uninitialized pointers because you found them all in your Debug builds. – sashoalm Oct 08 '16 at 18:13
  • @BlackMoses I'm not sure if MinGW is different. Keep in mind that the pointer's value is pretty random, and adding or removing local variables changes the uninitialized value so it might be hard to reproduce. – sashoalm Oct 08 '16 at 18:15
  • @sashoalm: I cannot, for the live of me, imagine a scenario, where an uninitialized pointer would cause a memory leak. And even if that were the case, you'd need to have 100% code coverage in your test cases to *"[find] them all in your Debug builds"*. A fine goal, but hardly ever reached in reality. – IInspectable Oct 08 '16 at 18:16
  • @IInspectable *memory corruption, sorry – sashoalm Oct 08 '16 at 18:16
  • Instead of hoping that all compilers implement s a feature like this to catch uninitialized pointers why not use RAII and always auto when dealing with pointers to have portable code that any debugger will catch the error? – NathanOliver Oct 08 '16 at 19:26
  • @NathanOliver: Because changing a large code base may be impractical. Suggesting to write perfect code, so that there is no need for tools to find bugs isn't exactly helpful either. Proper diagnostics should be the least you can expect from your compiler's support libraries. – IInspectable Oct 08 '16 at 19:46

0 Answers0