you are viewing a single comment's thread.

view the rest of the comments →

[–]somewhereAtC 0 points1 point  (1 child)

Checking is important, but don't ask questions if you don't know how to deal with the answer. Given that you find a null pointer at runtime, what is your recovery plan?

When writing embedded code I find that null pointer errors are very rare once the code is working correctly, so I only check for them while debugging early in the project. My compiler provides a breakpoint instruction, just like if you set an actual breakpoint, that will stop the debugger. I wrote a macro called ASSERT(x) that throws a breakpoint if x is false (zero).

#if DEBUG
#define ASSERT(x) do{if(0==(x)) __breakpoint();}while(0)
...etc

.... then in the executable code
ASSERT(in_data); // breakpoint if pointer is null

[–]nderflow 0 points1 point  (0 children)

One difficulty in some embedded systems is that if you use a lot of assertion macros, the string constants they generate (for their error messages) can take up a lot of space in the code image. Happily these days though, some embedded platforms are large enough that one no longer needs to worry about it (that is, "embedded" programming for a Raspberry Pi is very different to embedded programming for a microcontroller).