On Wed, Nov 2, 2016 at 12:37 PM, Joseph Myers <jos...@codesourcery.com> wrote: > On Wed, 2 Nov 2016, Jason Merrill wrote: > >> It seems to me that the general principle is that we should consider >> the location where the thing we're warning about is happening. In >> >> float_var = LLONG_MIN; >> >> The relevant location is that of the assignment, not the constant on >> the RHS. In your ?: example, a simple answer would be to warn based > > I'm not sure we track locations well enough to handle that yet. > > Say you have an implicit conversion of a function argument to the type > from the prototype and something about that conversion should be warned > about. Then you should obviously warn if the argument is a macro from a > system header but the call is outside a system header. But say the > function call itself comes from a macro defined in a system header - you > should still warn if the user passed an argument of the wrong type, even > if that argument is a macro from a system header. > > That is: > > /* System header. */ > int __foo (int); > /* This sort of macro to avoid accidental interposition issues has been > discussed lately on libc-alpha, so it's a realistic example. */ > #define foo(x) (0 + __foo (x)) > /* User code. */ > v = foo (NULL); > > should warn because the call to __foo logically results from user code > even though both NULL and foo are macros defined in system headers. I'm > not sure what the locations look like here.
Sure, the problem here comes from the user combining the two macros. I suppose in this case you could notice that the macro expansions of 'foo' and 'NULL' are not nested. Jason
