Re: Pointers to derived type objects in COMMON

Walter Spector <w6ws_xthisoutx@xxxxxxxxxxxxx> wrote:

Tobias Burnus wrote:
On Apr 27, 3:48 pm, Walter Spector <w6ws_xthiso...@xxxxxxxxxxxxx>
wrote:

"C589 (R558) If a common-block-object is of a derived type, it shall be
a sequence type or a type with the BIND attribute and it shall have no
default inititialization."

But what about *pointers* to the objects? If I merely want to place
a pointer to the object in the COMMON block, my reading of §5.5.2
says that it is legal to allow the pointer regardless.

Contrary to you, my reading is that this applies also to a pointer to
a derived type.

I can read it either way,

I don't really see how. I strongly agree with Tobias here. I think you
are confusing an important aspect of Fortran pointers with C ones. In
Fortran, pointer is an attribute. It does *NOT* make a separate type. If
the common-block-object has (derived) type x, then adding the pointer
attribute doesn't change the type. It is still of the same type and thus
the above restriction still applies.

If you try to read such words any other way, I think you'll find that
large parts of the standard fall apart - at least if one tries to apply
the same reading throughout the standard. For a basic example, I think
you'll have trouble explaining how pointers can ever get used in
expressions. If you track it down, you'll find out that they just come
in (via the bnf for designator) as object-name. No special rules about
whether it is or isn't a pointer; it is just object-name. If that
doesn't apply equally well to objects with the pointer atribute, then
You can't use pointers in expressions... which would be a bit awkward.

Now as to why the restriction is that broad, that is harder to answer. I
didn't even recall that particular bit until I rechecked the standard. I
would have thought there might be an exception for pointers, but in
order to be so, the exception would actually have to be written as an
exception or some such thing (perhaps just adding the word
"nonpointer").

Perhaps it was just a matter of not wanting to add more general
capability to COMMON (which some people would like to phase out). If so,
it is certainly plausible as a vendor extension. That doesn't
necessarily mean that the vendor interprets the above words differently.
(But if it is a vendor extension, there needs to be a capability to
diagnose it, the above being a constraint).

I guess it depends on how far one views the concept of a 'typed pointer'
extending.

See above.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
.

Relevant Pages

  • Re: A C++ Whishlist
    ... In the vast majority of member functions the first thing you will do ... If I feel it needs an extra check because it won't crash cleanly I may ... >> unless you also check the this pointer you aren't checking every ... The standard does not say "the this pointer cannot be NULL". ...
    (comp.lang.cpp)
  • Re: Pointer equality and dereferencing
    ... exact replica of the representation of a pointer is guaranteed to be ... sufficient to produce a semantically equivalent pointer, and if not, then ... Reading the C standard and this newsgroup I think that an exact replica ... dereference it with a defined behavior. ...
    (comp.std.c)
  • Re: libitery directory in gcc-3.1.1 source code package
    ... >> Even though the method of testing pointer alignment in the code above ... >> be written into the standard to provide a conformant means of writing ... discussion implicitly gives the opinion the status of fact. ... the description of the Cray character addresses is ...
    (comp.lang.c)
  • Dealing with "Han from China"
    ... standard itself. ... illustrated by gcc's default support for pointer arithmetic on void*. ... The other "regs", except Keith, ... pointed out possible error by James Kuyper and Ben Bacarisse ...
    (comp.lang.c)
  • Dealing with "Han from China"
    ... standard itself. ... illustrated by gcc's default support for pointer arithmetic on void*. ... The other "regs", except Keith, ... pointed out possible error by James Kuyper and Ben Bacarisse ...
    (comp.lang.c)