[PATCH] Check for null pointers given to memcpy with ubsan
Richard Smith
richard at metafoo.co.uk
Sun May 24 09:05:25 PDT 2015
On 24 May 2015 4:57 pm, "Nuno Lopes" <nunoplopes at sapo.pt> wrote:
>
> In http://reviews.llvm.org/D9673#170543, @samsonov wrote:
>
> > In http://reviews.llvm.org/D9673#170474, @nlopes wrote:
> >
> > > > Wait a second, won't UBSan handle this automatically if
memcpy/memmove are
> > >
> > > > declared with __attribute__((nonnull)) in the header? Otherwise,
is there
> > >
> > > > a change to the standard that imposes these additional constraints
on
> > >
> > > > memcpy/memmove?
> > >
> > >
> > > Not really. memcpy/memmove calls are handled by CGBultin and not
CGCall.
> > > It's a different code path.
> > > Nuno
> >
> >
> > Interesting. I think that if we decide to implement such a check, we
shouldn't depend on
> > attributes specified in the headers, so `nonnull-attribute` is no
longer relevant. There are another
> > kind of compiler builtins which worth extra checks, and which don't
even require headers - e.g. behavior of __builtin_ctz(0)
> > is undefined. I think we should implement another check kind
`-fsanitize=builtin` that would verify arguments of
> > various builtin functions.
>
>
> Well, I think in the end they are all in the UB category, so I think they
fall in the scope of -fsanitize=undefined.
We have sanitizer groups (much like warning groups); nothing goes directly
in -fsanitize=undefined.
> Nuno
>
>
> REPOSITORY
> rL LLVM
>
> http://reviews.llvm.org/D9673
>
> EMAIL PREFERENCES
> http://reviews.llvm.org/settings/panel/emailpreferences/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150524/fc70ca56/attachment.html>
More information about the cfe-commits
mailing list