Tom Lane wrote:
>
> I agree with Bruce on this one. I think the right analogy is not
> one of "let's be friendly if he passes a null pointer" but "should
> we try to detect a bogus input pointer". If we are passed a random
> bit-pattern for the 'from' pointer, we will almost certainly core
> dump on trying to dereference it. We have no reasonable or portable
> way to defend against that. I tend to think that being passed a null
> pointer is a member of this class of events, not something that we
> should have a special-case defense against. It is a caller bug and
> the caller should fix it, just the same as if the caller passed us
> a bogus non-null pointer.
Well, I can see your perspective and it sounds reasonable. Null ptrs are a
member of the general class called "bogus input pointers." But the fact that
you *can* detect a null ptr while you *cannot* detect a random bit pattern is
precisely why I think it ought not to be sub-classified in the same
things-we-defend-against category as the random bit pattern. You *do* have a
reasonable and portable way to defend against null, unlike the random bit
pattern.
Ed
