(j3.2006) Lock variables

Malcolm Cohen malcolm
Mon Mar 9 20:30:20 EDT 2009



Van Snyder wrote:
>
>>> Do we want to prohibit a lock variable from being an <output-item>?
>>>
>>>       
>> It's already done except for the case of defined i/o.
>>     
>
> It's not completely done.
Yes it is, or would be if the standard were not broken.  This is 
irrelevant to lock variables.
>
>> Where does it say unformatted write doesn't have to obey the requirement
>> that all
>>    "components shall be accessible in the scoping unit containing the
>> input/output statement"
>> ?
>>     
>
> That requirement is in 9.6.3p7, the second bullet in the list, at
> [09-007:220:6-10], which deals with derived-type list items that get
> decomposed into their components because at least one component is
> handled by defined I/O.

Well that would be rather obviously incorrect text in the standard then.

It is PRECISELY the case of intrinsic i/o that needs to be prohibited 
(and is, in F90/95).

Looks like a mistake adding defined i/o to me - along with adding the 
defined i/o exception we have broken the intrinsic i/o requirements.
>
> There is no such similar requirement in the third bullet, which deals
> with list items that don't get decomposed.  Down in the fifth bullet
> [220:18-20] (which ought to be part of the third one) it gets around to
> prohibiting ultimate components of derived-type list items that aren't
> decomposed from having the ALLOCATABLE or POINTER attributes.  But
> there's still nothing there about the ultimate components being
> accessible.  NOTE 9.34 suggests this was intentional.
>   
I disagree with your reading of note 9.34 comprehensively.  It is inline 
to a single bullet point and is addressing  that bullet point and that 
bullet point only.

Again, Fortran 90/95 disallow all (intrinsic) i/o (including 
unformatted) of types with private components, and I cannot believe such 
a stupid feature was a deliberate part of F2003.  Evidence please, on a 
postcard.

See 97-007r2 [149:1-2]
   "A derived-type object shall not appear as an input/output list item 
if any component ultimately in
the object is not accessible within the scoping unit containing the 
input/output statement."

Cheers,
-- 
.......................Malcolm Cohen, Nihon NAG, Tokyo.





More information about the J3 mailing list