(j3.2006) Variable definition context

Van Snyder Van.Snyder
Wed Apr 2 15:06:52 EDT 2014


On Wed, 2014-04-02 at 17:58 +0900, Malcolm Cohen wrote:
> >The first is the observation that in every reference to 16.6.7, other than the 
> >ones on page 316 concerning pure procedures, the objects discussed in relation 
> >to variable definition context are clearly nonpointer objects.

I should have added C1302 and C1303 to the list where something other
than "nonpointer" is stated or implied.

> Apparently so (not carefully checked).  I don't think it was always like that...
> 
> >I suspected that pointers of LOCK_TYPE are prohibited, but the closest thing I 
> >could find to prohibiting them is that targets of pointers cannot be coindexed 
> >objects.  That doesn't prohibit a pointer from having a target that is a 
> >coarray.
> 
> Named variables of type LOCK_TYPE are explicitly required to be coarrays, and 
> that does prohibit them from having the POINTER attribute.

Ahhh, yes.  C526.  Which says "ultimate component."  Maybe that's OK
here because a coarray component has to be allocatable, and so stops the
"ultimate" recursive descent.

It's interesting that if you have a coarray of any type other than
LOCK_TYPE (or EVENT_TYPE in the TS), you can associate a pointer with
it, but you can't associate a pointer with a variable of type LOCK_TYPE.
That's kind of perverse.

When I asked whether it is reasonable to prohibit a variable of
LOCK_TYPE from being the actual argument in a reference to C_LOC, the
answer was "no; there are reasonable things that could be done with it."
I can think of only one.  Once one has the C address of a variable of
type LOCK_TYPE, one can send it to a C function.  Hopefully, he doesn't
meddle with it; rather he just passes it to a Fortran procedure.  Then,
one might try to get at the lock by converting the C address back to a
pointer using C_F_POINTER, but that's prohibited by C626.  So, as far as
I can tell, there's nothing that can be done with the C address of a
lock variable.

> One might reasonably wonder why (apparently) it is ok to have a pointer 
> component of type LOCK_TYPE, but not a named variable.  One might leap to the 
> conclusion that there is a missing rule somewhere... otherwise we have a 
> mysterious inconsistency.  That or the rule requiring a named LOCK_TYPE variable 
> to be a coarray was accidentally strict and should have been "a coarray or a 
> pointer".  Who knows.

If it's allowed to be a pointer (which I think is the right thing to do
eventually), there needs to be a prohibition against allocating it.

> >The third reason is that one can imagine uses of LOCK_TYPE pointers, if they 
> >are allowed, but with the existing prohibitions in 16.6.7 one cannot associate 
> >them.

> I think I'd like feedback from the HPC subgroup first, on the apparent 
> inconsistency with LOCK_TYPE, before attempting to fix it.  As it is, making any 
> change here has significant technical effect and is therefore not editorial. 
> Might be a wart or an interp though.

I agree this would not be a simple editorial change.

I suggest that pointers of type LOCK_TYPE be allowed, but that one
cannot allocate a pointer of type LOCK_TYPE (or EVENT_TYPE).  That would
make the possibility of passing one's address through a C function to a
Fortran procedure possible.  One can also imagine, for example, a
Fortran procedure that figures out which lock to use, and provides the
result of that deliberation as a pointer of type LOCK_TYPE.

> Cheers,





More information about the J3 mailing list