On Mon, Dec 16, 2019 at 02:11:59PM +0000, Ramsay Jones wrote:
>
> Yep, this looks better. Thanks.
>
> However, ...
>
> It is interesting that both gcc and clang sometimes do/don't include
> the equivalent of the 'typediff' information. In the case of redeclared
> functions with different parameter types, etc., it seems they are
> content to display both function prototypes (including parameters) and
> let you deduce the information yourself! ;-)
Yes, indeed. OTOH, sparse doesn't display the argument's type,
which is often very annoying. I never tried to fix it, though.
> Note also, that sparse, gcc and clang all give different warnings and
> errors on 'validation/c11-atomic.c'! (sparse is not passed a --std=
> for either c11 or gnu11 - does that matter?)
No, it doesn't. But it more or less should since, standardwise,
_Atomic only exists since C11.
> thus:
>
> $ gcc --std=gnu11 validation/c11-atomic.c
> validation/c11-atomic.c:9:6: error: conflicting types for ‘f00’
> void f00(int dst) { } /* check-should-pass */
> ^~~
[snip]
> ... and for clang (does it understand --std=gnu11?):
I think so.
> $ clang --std=gnu11 validation/c11-atomic.c
> validation/c11-atomic.c:9:6: error: conflicting types for 'f00'
> void f00(int dst) { } /* check-should-pass */
> ^
[snip]
> [note that both gcc and clang complain about 'f00']
Yes, indeed. Quite interesting.
I wonder which version of gcc I used when I added this (I'm
kinda 99% sure I compared the output with gcc's but ...).
I tried to check this in the standard and at first I concluded
that sparse was right but a closer look made me think the contrary.
I really hate how things are specified in the standard.
So, from what I underdstand:
1) base rule: for type compatibility, only the unqualified types
matter.
2) the qualifiers are const, volatile, restrict & _Atomic
3) restrict is special anyway
4) for type compatibility _Atomic is special and must not be
ignored (which totally makes sense since its alignment and
even its size can be different than the base/unqualified type).
I'll fix this in the coming weeks.
Thank you very much for the review and for noticing this.
-- Luc
