Re: 'const' unnamed structures

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jan 20, 2021 at 11:21:46AM -0800, Linus Torvalds wrote:
> So the kernel was trying to use a unnamed struct to mark a group of
> fields as being 'const', and while gcc is perfectly happy with that,
> it turns out clang is not.

...
 
> Basically, I see two possibilities
> 
>  (a) since the const is there in the unnamed sub-struct, we can "fix"
> it at evaluate lo time, in find_identifier().
> 
>      We'd have to add a "unsigned int qual" as an argument - initially
> zero - to "find_identifier()", and then in the recursive unnamed
> union/struct case we'd or in the qualifiers for this one.
> 
>      And then we'd modify the symbol result as per the qualifier when
> we return it.
> 
> Honestly, (a) strikes me as ugly and wrong, but it might be simpler
> than what I think might be the right model:

Yes, and it would anyway need more than a simple "unsigned int qual"
because attributes (and alignment via _Alignas()) are also concerned.
But I don't think an additional argument is needed: merging the
modifiers, alignment and AS can be done inside find_identifier()
itself, in the recursive part. This would make it a little less ugly.

> Obviously, the third possibility is to say "ok, clang also gets this
> wrong, the clang people are trying to argue that the standard is not
> clear about it, and sparse might as well ignore this until it's a
> bigger problem".

Hehe, this third possibility is kinda tempting but for once the
standard seems quite clear to me (the grammar clearly allow it,
why it should then be ignored at the semantic level?).

I'll look at this in the next days.

-- Luc



[Index of Archives]     [Newbies FAQ]     [LKML]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Trinity Fuzzer Tool]

  Powered by Linux