Hacker News Reader

Comment by IshKebab | Hacker News Reader

The problem is that the type system doesn't encode whether a point can be null or not, so unless your documentation is amazing (I doubt it) you'll eventually end up getting passed a pointer from someone else, or giving a pointer to someone else who has a different assumption about whether null is allowed. Boom segfault.

There are several solutions in C++.

1. Always check for null. Kind of annoying and lots of people don't for whatever reason.

2. Use references. As you say, annoying because then you can't have null (sensibly) even when it would be really useful.

3. Use std::optional<int&> or something like that. I only just thought of this and don't know if it would work, but I bet it's a pain.

So no great solution. Personally I would use a smart pointer type, document it as well as I can, and always check for null.

View on HN

> so unless your documentation is amazing

As I pointed out I usually don't have null pointers at all. There might be a few places where a value can very obviously be null, but they are far and far between. No need for documentation.

> Boom segfault.

Which is exactly the right thing to happen (it's the C version of Exceptions in dynamic languages) since the code was incorrect.

> Always check for null. Kind of annoying and lots of people don't for whatever reason.

And now what do you do if you detected null but it was not allowed? Throw an exception? You can have that for free by just not checking.

> Use references. As you say, annoying because then you can't have null (sensibly) even when it would be really useful.

C++ references don't really protect you from NULL. It's just a different syntax for the same thing.

> Use std::optional<int&> or something like that. I only just thought of this and don't know if it would work, but I bet it's a pain.

Yes, pain, big pain. So much line noise and typing (in both senses) around what is essentially an int.

Just don't check. I don't get why there's so many places for null pointers. (As I said elsewhere, I don't have a solution for JSON style microscopic programming, and I don't care about that.).

How do C++ references not protect you from NULL ?

From the standard:

> A reference shall be initialized to refer to a valid object or function. [Note: in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the “object” obtained by dereferencing a null pointer, which causes undefined behavior. As described in 9.6, a reference cannot be bound directly to a bit-field. ]

Better try instead of reading standards (and inevitably misreading, or reading differently than compiler authors)...

    #include <stdio.h>
    void test(int& x)
    {
        printf("Hello, world\n"); fflush(stdout);
        printf("and the number is: %d\n", x);
    }
    int main(void)
    {
        int *x = NULL;
        test(*x);
        return 0;
    }

It's just a syntactic discipline. Null references are undefined in C++, just as NULL dereferences are undefined in C.

> Always check for null. Kind of annoying and lots of people don't for whatever reason.

use assert or some custom always-assert-even-on-release macro.

> Use references. As you say, annoying because then you can't have null (sensibly) even when it would be really useful.

well, only use references for non nullable pointers. Otherwise use plain (or smart) pointers.

> Use std::optional<int&> or something like that. I only just thought of this and don't know if it would work, but I bet it's a pain.

std::optional<T&> is unfortunately not part of C++17, mostly because people couldn't agree on operator= semantics:

int x = 1; int y = 2; std::optional<int&> oint = x;

oint = y; // which one is true? assert(x == y); // deep assign assert(&*oint == &y); // rebind

boost::optional supports references and IIRC rebinds on plain assignment.

For parameters where you aren't transferring ownership, just use raw pointers/references. If it's a required parameter make it a reference. If it's optional, use a pointer and check for null.

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.

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.

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.

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).

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.

Reply on news.ycombinator.com