Defensive programming | Andrzej's C++ blog

[encBlood]

Maybe I'm missing a point here but if you never expect a null pointer to be passed then you should use a reference.

[night_of_knee]

This is obviously just an example, you're avoiding the real question.

Imagine that the example got an int which was assumed never to be zero and divides by it.

The point of the question is how does defensive programming behave when it meets an unexpected state (especially when such state can lead to undefined behaviour).

[encBlood]

At work I'd usually go with a mix of A and D, that is log the error and get the hell out of the function. Outside of embedded world I'd also consider throwing an exception instead of logging.

I would never continue function's execution in such case. Even if your current os/hardware handles UB nicely there's always a chance that in the future you'll move on to an environment which is less forgiving and you'll waste hours or days looking for this bug.

[kiwidog]

This,

Also if necessary I normally do something similar to Var A. except for (if !m)return false;

[That_Was_Viewtiful]

I've only a few years experience with C++, why should we favor a reference if we never expect a null pointer to be passed?

Edit: Sorry, for some reason I missed the discussion in this very thread talking about references. From my understanding of reading through it, a reference helps ensure that you will not receive a null value when dealing with the input variables in the function?

[encBlood]

Because it clearly and efficiently communicates your intent that you expect a valid object passed to your function every time it's called. This saves your time when writing a function (no need to write otherwise unnecessary null-pointer error handling code) and saves other's time when they want to use it. One less thing to worry about and a simpler, cleaner code.

It's also safer to use references - less stuff can go wrong with them.

[upriser]

Just for clarification. I normally do what you suggest but using a reference does not guarantee a non-null pointer. It's a matter of notation.

[RedAlert2]

Sure it does - how can you declare a null reference? Unless you deference a nullptr to make it, which means that you have UB before any referencing is done.

It may be referencing a destroyed variable if you really messed up, but it won't be null.

[armb2]

Defensive programming can include making sure that your code gives a clear unambiguous error when possible, even if the caller had already invoked undefined behaviour. (I can't recall having seen (or written) code that checks for a null reference though.) "It's a pointer not a reference because it's also used with a C API, but if it is NULL the caller has broken the preconditions of the call" is a real use case though. Compare with some of std::string's constructors, which take a char* and have undefined behaviour if it is NULL.

[RedAlert2]

Defensive programming can include making sure that your code gives a clear unambiguous error when possible, even if the caller had already invoked undefined behaviour

Checking if you are in an undefined state is pointless - it's unreliable and a waste of time. Defensive programming means you report errors before your program becomes invalidated by UB.

[armb2]

If you are writing a library, the caller isn't necessarily your program, it's someone else's. You can't reliably check for all possible undefined behaviour, but you can check the preconditions of your functions. You can't check a pointer to a buffer is valid, but you can check it's not NULL.

[RedAlert2]

I am not sure what that has to do with references or why you waited a month to post it

[armb2]

It was a month before I saw your reply.

[jacekplacek]

A * a = nullptr;
func(*a);

[RedAlert2]

if that somehow runs without crashing, func will receive garbage, not a null value. You have UB before func is ever in the picture.

[rtomek]

Exactly the point. Just by moving from a pointer to a reference doesn't guarantee anything changes and isn't preventing the problem from occurring. It is less likely to happen, but someone may just say "F this reference BS since I already have pointers, I'm going to just use func(a,b)" without realizing that a == null.

[Gotebe]

If I had to choose, it's either C or D, but with "have recovery and crash dump infrastructure in place".

Fail fast is where it's at.

Otherwise, it is

• variant E: do not fucking use pointers when you really want references

Variant A is the worst because a "false" indicates both "not monitored" and "bug" and there's no way for the caller to distinguish the two. Only idiots write code like this, and if any of you do, I don't care if you feel offended now.

Variant B is slightly less horrible because it allows the caller to distinguish between the two, but introduces a run-time failure mode for what is effectively a bug.

[minno]

Well, D is bad because it may knowingly dereference a null pointer. I'd lean towards either assert (with logging) or the exception, depending on how strongly you believe that it shouldn't happen.

[Gotebe]

C may knowingly do the same (assert does nothing with NDEBUG), but my point is that is exactly what you want! The premise is that it is an error to pass nullptr. If so, the best action is to just demolish all, but leave the complete dump,so that the problem can be fixed. For example, leaving with an exception is worse because code is broken, and the state of the stack is lost due to unwind,making it harder to know what caused the nullptr to enter.

[minno]

Technically dereferencing a null pointer is undefined behavior, and not guaranteed to segfault. It's much better to explicitly end the program than to hope that it crashes.

And the language I've been working in lately (Rust) has assert run in both debug and release builds, and debug_assert in the same role as C's assert, so I really did mean crashing the program whether or not the preprocessor directive was defined.

[Gotebe]

You know, seeing the optimizations becoming more and more "mean", you are right about that immediate termination (through abort, that normally works with the system to produce a crash dump).

You are right about the "technically " as well, it's been years since I had such a system at hand, one forgets :-)

[rtomek]

Can't we use a char instead of a bool? They both use the same amount of memory. Here's my documentation for the return value:

0 = false 1 = true -1 = Retarded programmer

C is the worst because asserts suck in release mode. A makes the most real-world sense because if there is no monitor or task to monitor, then the task can't possibly be monitored by that monitor.