[pjmlp]

The problem in C derivative languages is that it isn't enough.

There is no guarantee that the pointers are valid, even if not null.

So besides checking for null, to be correct we need to call OS APIs to check for pointer integrity as well.

[smelterdemon]

That's on the client code. You can't stop callers from doing something stupid (or cosmic rays from flipping bits). At that point crashing fast is preferable.

[pjmlp]

I disagree, the premise of design-by-contract and clean code methodologies is that functions must ensure the integrity of the data handled by them.

[jstimpfle]

That's theoretic talk. Try doing it in practice and still get things done / be able to maintain the code / see the forest for the trees.

But I have a feeling that we are lacking a bit of context here. Some people seem to focus on web-application style of programming (understandably) where you have lots of trust issues. Whenever data is carried across trust boundaries it needs to be checked (this applies to integrity in general, of which null safety is just a small part).

(On the other hand, deserialization is not about validation of function arguments. Deserializers should assert integrity on the spot before calling into deeper nested functions).

[pjmlp]

I did it in practice, during the MFC's glory days, several years ago.

Making use of ASSERT_VALID(), VERIFY(), AfxCheckMemory(), AfxIsValidAddress(), AfxIsMemoryBlock() and many other helper functions.

A style enforced at the company's code reviews, which helped a lot our code quality.