[cfe-commits] PATCH: Enhance array bounds checking

David Blaikie dblaikie at gmail.com
Thu Jul 14 10:40:05 PDT 2011


>
> Do we really want this to be a warning?
>

5.7/5 allows for well defined behavior when a pointer points to one past the
end of an array, but is not dereferenced (I haven't fully comprehended which
cases are allowed & denied by this change, though - so I'm just stating this
for completeness) & this is often used for iterator pair semantics.


> There are plenty of examples where an out-of-bounds pointer is computed for
> legit reasons.  As long as that address is not dereferenced, there isn't
> necessarily a problem.  I'm fearful this may generate a fair amount of noise
> on codebases that do elaborate tricks with pointer offsets.  Indeed this
> very example doesn't actually exhibit a "bug".
>

Indeed even in the examples given, "Foo" + 5, makes a fair amount of sense -
"Foo" has 4 elements, so "Foo" + 5 is the end iterator for that range. I'd
say for that case we'd want to be conservative about warning - but could
possibly still do so, certainly if we could prove it was dereferenced (but
if it's just being passed to a function & we're not doing interprocedural
analysis to check that the function doesn't dereference it, we can only
guess - either by providing a separate warning class, or not warning at all)

For other offsets - before the beginning or more than one past the end,
that's a bit more questionable. If clang/LLVM already does optimizations
that could break these assumptions, it might be worth erring on the side of
caution & warning. If someone really knows how to make those tricks work,
even in the presence of compiler optimizations, they can suppress the
warning.

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110714/7862a144/attachment.html>


More information about the cfe-commits mailing list