Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!wuarchive!mit-eddie!bloom-beacon!eru!hagbard!sunic!dkuug!diku!thorinn
From: thorinn@diku.dk (Lars Henrik Mathiesen)
Newsgroups: comp.std.c
Subject: Re: Interaction between storage class and qualifiers
Message-ID: <1991Jan8.213415.19295@odin.diku.dk>
Date: 8 Jan 91 21:34:15 GMT
References: <2760@charon.cwi.nl> <1991Jan8.011724.25209@jituha.enet.dec.com>
Sender: news@odin.diku.dk (Netnews System)
Organization: Institute of Computer Science, U of Copenhagen
Lines: 90

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

I read this to mean that GCC took both declarations as "register
pointer to volatile struct foo" (as it should). Below, you seem to
think that GCC made the pointer volatile.

ND>Interesting.  I thought this would be well defined in the standard
ND>(i.e. that p2 has to be the same as p1) but it isn't.
ND>Section 3.5 includes the following excerpts (except for line numbers):
ND> [grammar rules deleted, and references to them below]
ND>    The declaration specifiers consist of a sequence of specifiers
ND>  that indicate the linkage, storage duration, and part
ND>  of the type of the entities that the declarators
ND>  denote.

I think the problem is the wording "the entities that the declarators
denote". A priori, it might well mean what you seem to assume
(something like "operands of the same form as the declarators", see
the formulation in 3.5.4 Semantics). It might also mean "the
identifiers declared by the declarators"; as I'll argue below, and
knowing what was intended, that's probably the best interpretation.

Note that it says "part of the type" --- if the first meaning was
intended, the type-specifiers and type-qualifiers here would give the
precise type of the "entity", not just part.

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

I'll just comment on the results you get when you make the same
assumption as I do.

ND>OK, let's pretend that section 3.5 says "identifier" (fixed up somehow)
ND>instead of "declarator".  (Mr. Gwyn will doubtless assert that it already
ND>says that.)
ND>Now, what does it say about:
ND>  register const int *a;
ND>register, const, and int all describe a?
ND>Everyone obeys this with regard to "register".

Yes.

ND>No one obeys this with regard to "int".

I think they do, because here's where the "part of the type" comes in.
If you read the explanation in 3.5.4 Semantics, and then read 3.5.4.1
(Pointer declarators), you'll see that the type of a in "int *a" is
determined like this:

  "int *a" has the form "T D1", where T == "int" and D1 == "* a"
  So D1 has the form "* D", where D == "a"
  In the declaration T D, that is "int a", the type specified for a is
integer.
  Therefore, the type specified for a in "int *a" is pointer to integer.

So integer really is part of the type of the identifier declared.

ND>Everyone thought that this should be obeyed with regard to "const".
ND>Again, SGI is inconsistent.
ND>GCC always obeys it.

I think you got this backwards, perhaps. "const int *a" declares a
pointer to a readonly integer, and that's what GCC takes it to do. In
your terms, that would be disobeying this interpretation of 3.5,
wouldn't it?

ND>Section 3.5 needs to be fixed.  SGI needs to be fixed.  I predict that,
ND>if section 3.5 is fixed, GCC's behavior will be correct.

Section 3.5 could certainly do with a better wording, but once you
know what's intended, it's not wrong. SGI is wrong.

--
Lars Mathiesen, DIKU, U of Copenhagen, Denmark      [uunet!]mcsun!diku!thorinn
Institute of Datalogy -- we're scientists, not engineers.      thorinn@diku.dk