On 10/20/2019 07:27 AM, Iain Sandoe wrote:
Martin Sebor <mse...@gmail.com> wrote:
On 10/19/19 2:56 AM, Iain Sandoe wrote:
Andreas Schwab <sch...@linux-m68k.org> wrote:
On Okt 19 2019, Iain Sandoe <i...@sandoe.co.uk> wrote:
This test has failed always on Darwin, because Darwin does not mark
entries in string.h with nonnull attributes. Since the purpose of the test
is to check that the warnings are issued for an inlined function, not that
the target headers are marked up, we can provide locally marked up
function declarations for Darwin.
If the test depends on the non-std declarations, then it should use them
everywhere.
from my perspective, agreed, Martin?
I don't see a problem with it. I prefer tests that don't depend
on system headers to avoid these kinds of issues
We can do that anyway then, - I can just adjust the current code tor remove the
special-casing, and to use __SIZE_TYPE__ instead of size_t everywhere, OK?
Sure.
That said, it shouldn't matter if the declaration of a built-in
function has the nonnull attribute. As long as the built-in has
one and isn't disabled GCC should use it. I'd be curious to know
what is actually preventing the warning from triggering there.
This is secondary problem, the Darwin header implementation expands th
memcpy to:
__builtin___memcpy_chk (dst, src, __builtin_object_size (dst), len);
Which, obviously, isn’t doing what you expect.
That suggests -Wno-system-headers might be getting in the way of
the warning. I thought most middel-end warnings coped with it
but maybe not this one. But getting rid of the include does
sound like the right way to deal with the test failing.
Thanks
Martin
So, this does suggest that
a) for the test to be well-controlled, we need to avoid system headers
b) there might be some other builtins to check.
(but if we restrict the discussion to my understood purpose of the Wnonnull
test, only (a) matters and that’s what’s proposed above).
thanks.
Iain
