Pointers to derived type objects in COMMON
Walter Spector
Consider the following:
subroutine commonptr ()
implicit none
type wws_t ! No SEQUENCE and has default initialization
integer :: x = 1, y = 2, z = 3
end type
type (wws_t), pointer :: my_wwsptr
common /block/ my_wwsptr
allocate (my_wwsptr)
my_wwsptr = wws_t (3, 4, 5)
end subroutine
We all know that for a derived type object to reside in COMMON, it
must have a SEQUENCE attribue, and must not have default initialization
specified. These are documented in constraint C589 in §5.5.2 of F2003:
"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. PGI and
Salford/Silverfrost allow the above code. However ifort, gfortran,
g95, IRIX f90, and others do not allow it.
Opinions?
W.
Tobias Burnus
wrote:
> type wws_t ! No SEQUENCE and has default initialization
> integer :: x = 1, y = 2, z = 3
> end type
> type (wws_t), pointer :: my_wwsptr
> common /block/ my_wwsptr
As follow up question: What if there is a SEQUENCE attribute? Is this
then valid or not? (The default initializer does not get applied to
the pointer, only to its target. Thus there is no reason why it should
be invalid --- unless C589 does not allow it.)
> "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.
However, even if it does not apply (then see my question above), one
can argue that without SEQUENCE it is invalid:
a) "A data pointer shall be storage associated only with data pointers
of the same type and rank." (§5.5.2.3)
b) "Data entities in different scoping units also have the same type
if they are declared with reference to different derived-type
definitions that specify the same type name, all have the SEQUENCE
property or all have the BIND attribute, have no components with
PRIVATE accessibility, and have type parameters and components that
agree in order, name, and attributes." (§4.5.1.3)
c) "A pointer occupies a single unspecified storage unit that is
different from that of any nonpointer object and is different for each
combination of type, type parameters, and rank." (§16.4.3.1, (8))
d) "Named common blocks of the same name shall be of the same size in
all scoping units of a program in which they appear" (§5.5.2.4)
Glue this all together and you see the SEQUENCE is needed. (Unless the
same TYPE is host/use associated in all scoping units where that
COMMON block appears; then we are back at asking whether C589
applies.)
Tobias
Walter Spector
> On Apr 27, 3:48 pm, Walter Spector <w6ws_xthiso...@earthlink.net>
> wrote:
>> type wws_t ! No SEQUENCE and has default initialization
>> integer :: x = 1, y = 2, z = 3
>> end type
>> type (wws_t), pointer :: my_wwsptr
>> common /block/ my_wwsptr
>
>
> As follow up question: What if there is a SEQUENCE attribute? Is this
> then valid or not? (The default initializer does not get applied to
> the pointer, only to its target. Thus there is no reason why it should
> be invalid --- unless C589 does not allow it.)
It seems to me that default initialization should work, if a derived
type object were used in conjunction with a BLOCK DATA routine.
However I see no verbage allowing it in the Standard. Another wierdness...
In any event, my current concern is with pointers to derived type objects.
>> "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, and compiler developers have implemented
it both ways.
I guess it depends on how far one views the concept of a 'typed pointer'
extending.
> [a number of good references deleted]
> Glue this all together and you see the SEQUENCE is needed. (Unless the
> same TYPE is host/use associated in all scoping units where that
> COMMON block appears; then we are back at asking whether C589
> applies.)
In my case, not the minimal code presented upthread, the code obtains
the definition of the derived type via USE association. So any place
where the common block appears (currently that can be counted on one
finger), the same type would be consistently used.
Tobias, I appreciate your interest in this!
W.
Richard Maine
> Tobias Burnus wrote:
> > On Apr 27, 3:48 pm, Walter Spector <w6ws_xthiso...@earthlink.net>
> > 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
Walter Spector
> ...
> 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
Thank you Richard, I was afraid of that!
> Now as to why the restriction is that broad, that is harder to answer...
I wonder if anyone ever gave it much thought.
An easy way to muck with innards of an F90 pointer is to put it (or a copy
of it) in a COMMON block. But the generality of this approach is ruined because
only a subset of pointers are allowed to reside in COMMON.
It seems to me that the pointers should be allowed. Perhaps, as you say,
the single word "nonpointer" could be added to the constraint.
W.