About some bugs

[bearophile]

Simen kjaeraas:

> bearophile <bearophileHUGS at lycos.com> wrote:
> 
> > Simen kjaeraas:
> >
> >> Much more likely would be the idea that has been discussed, of opt-in
> >> non-nullness, by disabling the default constructor for a struct that
> >> wraps a pointer.
> >
> > I am not sure that's enough.
> 
> Could you please show a case where it isn't?

We have discussed this a lot in past, I repeat because in this newsgroup I have learnt that sometimes you need to repeat things many times before most people start to notice.

First of all it's a matter of syntax. Attaching a "@" to a reference/pointer type to turn it into a nonnullable is not the same thing as using a special struct:

class T {}
T nullable_reference;
T@ nonnullable_reference = new T@();

struct S {}
S nullable_pointer;
S@ nonnullable_pointer = new S@();

void foo(T@ x) { ... }


A handy short syntax is able to turn something from a seldom used feature, to an idiom most people in the community use. Python language designers have understood this well.

Then, I was talking of two features present at the same time. The first is nonnullable rerefence types, and the other is a bit of flow analysis that essentially gives a possible-null / surely-not-null state to a type:

S s = new S;
...
if (s != null) {
    // here s is essentially a S@
}


It avoids bugs like:

static int rose_rebuild_header(struct sk_buff *skb)
{
    ...
    if (!rose_route_frame(skbn, NULL)) {
        kfree_skb(skbn);
        stats->tx_errors++;
        return 1;
    }
    stats->tx_packets++;
    stats->tx_bytes += skbn->len;
    ...
}

The bug here is that in some cases skbn the code calls free on skbn, so at the end of the if{} yuou can't perform skbn->len in all cases. The type system has to denote this as a possible bug.

Just disallowing standard constructors is useful, but it's not enough.

Bye,
bearophile