Simen kjaeraas:
> bearophile <[email protected]> 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
