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)
  • Errata for The C Programming Language, Second Edition, by Brian Kernighan and Dennis Ritchie
    ... Today I found out that the official page of errata for The C Programming Language, Second Edition, by Brian Kernighan and Dennis Ritchie is down: ... The first printing of the book was made before the Standard was finalized; these copies say "Based on Draft-Proposed ANSI C" on the front cover. ... ``A pointer may be converted to another pointer whose type is the same except for the addition or removal of qualifiers of the object type to which the pointer refers. ...
    (comp.lang.c)
  • Errata for The C Programming Language, Second Edition, by Brian Kernighan and Dennis Ritchie
    ... Today I found out that the official page of errata for The C Programming Language, Second Edition, by Brian Kernighan and Dennis Ritchie is down: ... The first printing of the book was made before the Standard was finalized; these copies say "Based on Draft-Proposed ANSI C" on the front cover. ... ``A pointer may be converted to another pointer whose type is the same except for the addition or removal of qualifiers of the object type to which the pointer refers. ...
    (comp.std.c)
  • Re: why cannot assign to function call
    ... hypothetical C-like languages, ... sizeof business would still indicate that a pointer was being passed. ... talk about variables of an array type. ... the earlier version of the standard didn't have numbered ...
    (comp.lang.python)
  • 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)