Interaction between storage class and qualifiers

[Norman Diamond]

In article <2760 at charon.cwi.nl> jack at cwi.nl (Jack Jansen) writes:
>The SGI C compiler treats the following two pointers as unequal:
>	register volatile struct foo *p1;
>	volatile register struct foo *p2;
>p1 is a pointer (in a register) to a volatile struct foo, while
>p2 is a volatile pointer (in a register) to a struct foo.
>
>Gcc treats the pointers as identical, and in my opinion this is
>as it should be. However, I haven't been able to find anything in
>the standard about the interaction of storage classes and type
>qualifiers. Since the 'register' in the declaration of p2 already
>refers to the variable p2 it is argueable that the volatile in front
>of it can't refer to the structure anymore.

Interesting.  I thought this would be well defined in the standard
(i.e. that p2 has to be the same as p1) but it isn't.
Section 3.5 includes the following excerpts (except for line numbers):
   (1)  declaration:
   (2)    declaration-specifiers  init-declarator-list/opt
   (3)  declaration-specifiers:
   (4)    storage-class-specifier  declaration-specifiers/opt
   (5)    type-specifier  declaration-specifiers/opt
   (6)    type-qualifier  declaration-specifiers/opt
   (7)  init-declarator-list:
   (8)    init-declarator
   (9)    init-declarator-list  ,  init-declarator
  (10)  init-declarator:
  (11)    declarator
  (12)    declarator  =  initializer
    The declaration specifiers (line 3) consist of a sequence of specifiers
  that indicate the linkage (line 4), storage duration (line 4), and part
  of the type of the entities (lines 5, 6) that the declarators (line 11)
  denote.
Section 3.5.4 tells what kinds of entities declarators can denote:
  (13)  declarator:
  (14)    pointer/opt  direct-declarator
  (15)  direct-declarator:
  (16)    identifier
  (17)    (  declarator  )
  (18)    direct-declarator  [  constant-expression/opt  ]
  (19)    direct-declarator  (  parameter-type-list  )
  (20)    direct-declarator  (  identifier-list/opt  )
  (21)  pointer:
  (22)    *  type-qualifier-list/opt
  (23)    *  type-qualifier-list/opt  pointer
Section 3.5.3 "constrains" the qualifiers:
    The same type qualifier shall not appear more than once in the same
  specifier list (line 3?) or qualifier list (lines 22, 23?), either
  directly or via one or more typedefs.
(Section 3.5.3 does not contain a forward reference to section 3.5.4, but
both of these references are the best interpretations that I can guess.)

At least, it seems that "register const" and "const register" both refer
to the same entity.  Which entity it is, we will determine in a moment.
Nonetheless, either p1 and p2 are the same, or else *p1 and *p2 are the
same.  SGI seems to be broken.  Now, what about GCC?

OK, so what does section 3.5 say about:
  register const int *a;
register, const, and int all describe *a, because *a is the entity denoted
by line 11.  Hmm, section 3.5 seems to be in trouble.
No one, but no one, obeys section 3.5 with regard to "register".
Everyone, but everyone, obeys section 3.5 with regard to "int".
Everyone THOUGHT that it should be disobeyed with respect to "const".
But SGI accidentally obeys it sometimes, while disobeying it other times.
GCC never obeys it.

OK, let's pretend that section 3.5 says "identifier" (fixed up somehow)
instead of "declarator".  (Mr. Gwyn will doubtless assert that it already
says that.)
Now, what does it say about:
  register const int *a;
register, const, and int all describe a?
Everyone obeys this with regard to "register".
No one obeys this with regard to "int".
Everyone thought that this should be obeyed with regard to "const".
Again, SGI is inconsistent.
GCC always obeys it.

Section 3.5 needs to be fixed.  SGI needs to be fixed.  I predict that,
if section 3.5 is fixed, GCC's behavior will be correct.
--
Norman Diamond       diamond at tkov50.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.