Re: Fix UDF-FS potentially dereferencing null

[Linus Torvalds]

On Thu, 22 Apr 2004, Alexandre Oliva wrote:
> 
> > "safe" to my mind means that not only is it not NULL, it's also safe to 
> > dereference early (ie "prefetchable"), which has a lot of meaning for the 
> > back-end.
> 
> And how far back can this go?

Hey, "sparse" is some way away from actually generating code, so I don't
know what the answer will be. From a checking standpoint, it's a fairly
easy attribute: right now it is an attribute on the "pointer", not on the
thing it points to (unlike the "address space" attribute, which means that
the thing the pointer _points_ to is of a different type), and that means
that your example will not cause any warnings (a "safe" pointer and a
normal pointer are compatible as pointers - they both point to the same
thing, so assigning from one to the other is not something we'd warn
about).

>From an actual code generation standpoint, let's see if we ever get there.  
I can see several semantically meaningful barriers ("can't move it past
the assignment of the pointer" or even the very limited "can't move it
past that one syntactic expression"), but it would depend a lot on what
the back-end actually would/could do and keep track of.

In your example, both pointers were called "p", but they were obviously
two different symbols from a compiler perspective. So there's a clear
"assignment" from one "p" to the other "p" as part of the inline function
call, so it's not like the back-end doesn't see that part - it's assigning
from a non-safe pointer to a safe one _after_ doing the test on the
non-safe one.

As such it's perfectly clear to the compiler what is going on in your
example; it's just a practical matter of taking it into account at the
right time. Whether that is a realistic thing to do, and worth doing, I
really don't know.

So I'll just claim that the "safe" attribute at least in theory makes
sense. Whether it matters in practice I'll leave to others.

> GCC's nonnull attribute is indeed useless for these purposes.  Even
> though the docs say it could be used to optimize away a NULL test, its
> syntax is far too cumbersome, since you apply the nonnull attribute to
> the function, not to its argument, which makes it unusable for
> non-argument variables.

Ahh. I didn't even know how the gcc nonnull thing worked. I just knew from
the gcc lists that something like that existed, and I just stupidly
assumed that it was done the sane way (ie the way I did it - which is, of
course, the very definition of "sane" ;).

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/