Hi Martin, Martin Sebor <mse...@gmail.com> wrote:
> 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. Will try to get to it later today. (also to backport to 9 and 8 if that’s OK, IIRC the test was introduced in 8.x - slowly catching up on long-standing Darwin test fails). >>> 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. In this case it seems like the Darwin headers are applying _FORTIFY_SOURCE (at least to the strings.h) automatically when the compiler is __GNUC__. It might be yet more fallout from the various __has_xxx that we don’t yet support. In any case, a separate issue I think. thanks Iain > > 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
