3 ms·

Just try that when debugging an app on an embedded system, mobile, or a console, where you have access to the console but no core dump. Sorry, but I agree with

Just try that when debugging an app on an embedded system, mobile, or a console, where you have access to the console but no core dump. Sorry, but I agree with all the folks who say printf (and similar) is categorically more useful when it prints "(null)". I've had many obscure crashes on systems that were precisely because a logging printf in a seldom-tested piece of code had a parameter that sometimes was correctly null would crash it out. If the debugger isn't attached and we just have a crash dump we can't read (happens even on platforms where you're SUPPOSED to be able to read them), then we have to attach the debugger and hope that we can reproduce the obscure state that caused the crash. Anything that makes debugging statements more robust and less crash-prone is a good thing. End of story. As others have said, if you want something to verify that a pointer is non-null, use an assert().

cperciva 11y ago
As others have said, if you want something to verify that a pointer is non-null, use an assert(). I said that, too. But sometimes developers don't think to put in every possible assert. Having the C library explode violently when it detects a bug in their code even when they forgot to include an assert which checks for that bug will help to find bugs under such circumstances.
- kazinator 11y ago
  In the environment under question, you do not need an assert. You just have to dereference the pointer. Unless the pointer is displaced past the unmapped page zero (i.e you're accessing str[4096] and above, and not touching str[0] through str[4095] on a system with 4K pages) you will get a fault resulting in a fatal signal: SIGSEGV. Whereas an assertion will get you a SIGABRT, but the result is the same. The assertion will be earlier, that's all, before you try to dereference the pointer. Probably not much earlier. Environments that do not have the hardware-assisted detection for null dereferences can still be targetted by a compiler which generates code which does the check on pointer dereference. That can be included in your debug builds, or even left in production builds if the performance impact is acceptable. I seem remember that some compilers for the Intel 8088 MS-DOS environment had a code generation option for trapping nulls.
- SomeCallMeTim 11y ago
  >will help to find bugs under such circumstances. Will help to crash your code when you use printf, which (in game development in particular) is 99% for debugging statements. No, having the C library explode violently at any opportunity does not always help detect bugs, and can be 100% harmful. You're overgeneralizing your own bug circumstances and development environment. That said, if it matters that much to you, wrap printf with a modified version that asserts on NULL-ish pointer dereferences. Don't attempt to roll back the clock on library development for everyone.

cperciva 11y ago

As others have said, if you want something to verify that a pointer is non-null, use an assert(). I said that, too. But sometimes developers don't think to put in every possible assert. Having the C library explode violently when it detects a bug in their code even when they forgot to include an assert which checks for that bug will help to find bugs under such circumstances.

kazinator 11y ago
In the environment under question, you do not need an assert. You just have to dereference the pointer. Unless the pointer is displaced past the unmapped page zero (i.e you're accessing str[4096] and above, and not touching str[0] through str[4095] on a system with 4K pages) you will get a fault resulting in a fatal signal: SIGSEGV. Whereas an assertion will get you a SIGABRT, but the result is the same. The assertion will be earlier, that's all, before you try to dereference the pointer. Probably not much earlier. Environments that do not have the hardware-assisted detection for null dereferences can still be targetted by a compiler which generates code which does the check on pointer dereference. That can be included in your debug builds, or even left in production builds if the performance impact is acceptable. I seem remember that some compilers for the Intel 8088 MS-DOS environment had a code generation option for trapping nulls.
SomeCallMeTim 11y ago
>will help to find bugs under such circumstances. Will help to crash your code when you use printf, which (in game development in particular) is 99% for debugging statements. No, having the C library explode violently at any opportunity does not always help detect bugs, and can be 100% harmful. You're overgeneralizing your own bug circumstances and development environment. That said, if it matters that much to you, wrap printf with a modified version that asserts on NULL-ish pointer dereferences. Don't attempt to roll back the clock on library development for everyone.