[llvm-dev] warning for overloads of builtins

[Michael Benfield via llvm-dev]

I'd like to implement an attribute to allow Fortify diagnosing of new
functions as if they were builtins. I'd appreciage any feedback about the
design.

An example illustrating a warning I'd like to happen:
///////////
void* memset(void* const s __attribute__((pass_object_size(0))),
             int c,
             int n) __attribute__((overloadable)) {
  return __builtin_memset(s, c, n);
}

int main() {
  char s[10];
  memset(s, 0, 11);
}
//////////

Ideally Fortify would be able to diagnose the overflow in the call to this
overloaded memset. Apparently this used to happen, but it stopped working
after this patch (https://reviews.llvm.org/D77491).

The design I'm thinking would involve adding a new diagnose_as_if
attribute, so that we could indicate that function calls to one function
should be diagnosed as if they were calls to another. For instance, it
might look like this:

//////////void* mymemset(void* const s,
             int c,
             int n) __attribute__((diagnose_as_if(__builtin_memset(s, c,
n)))) {
  return __builtin_memset(s, c, n);
}
///////

I see several ways the diagnose_as_if attribute could work:

1. diagnose_as_if(__builtin_memset) (just diagnose `mymemset` as if it's a
call to __builtin_memset, with arguments in the same order)

2. diagnose_as_if(__builtin_memset(0, 1, 2)) (use integers to specify which
parameters of the call to `mymemset` go in which argument of
`__builtin_memset`)

3. diagnose_as_if(__builtin_memset(s, c, n) (use parameter names to specify
which parameters of the call to `mymemset` go in which argument of
`__builtin_memset`)

4. As an extension to item 3, potentially the arguments of
`__builtin_memset` could be more complicated expressions than just names of
parameters, like `__builtin_memset(s + 2, c, n)` or something. It seems
this would be more complicated to implement.

It's not immediately clear how much generality would be useful here; would
option 3 be sufficient? Or even option 1?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210921/85fa9249/attachment.html>