I am not sure if this is a bug or a very arcane C standard: perhaps some clarification is needed.
How is it syntactically correct when parsing C to have a duplicate qualifiers like const or static on a primitive type like int or char?
Example:
const const static static unsigned unsigned int foo = 0;
This behavior is exhibited in both the AST as well as in higher level usages e.g. Xcode's syntax highlighter.
Granted the attributes are not conflicting, but should this not generate a warning (which it seems that clang does not have such a warning for duplicate qualifiers applied as such). However I understand the reason why this does not generate an error since there is no inherit conflict between the qualifier list.
It is understandable that a pointer-pointer could potentially have two const qualifiers; one to determine the first indirection's "const-ness" and another to determine the second indirection's "const-ness". Is there some other reasoning similar for primitive types to have this as well, or have I just missed the boat on some flag somewhere?
As a side note GCC pitches a fit about the duplication of static or unsigned but not a peep about the double const.
Thanks for any help with this,
Philippe Hausler