(j3.2006) J3 Fortran interp letter ballot #22 - due 19-Nov-2010

Van Snyder van.snyder
Mon Oct 18 02:45:49 EDT 2010

Malcolm Cohen wrote:
> Van Snyder wrote:
>> ---  -N-  F03/0124   definition is poorly defined
>>          The answer implied by the edits is too restrictive.
> The answer is less restrictive than the text currently in the standard, in that 
> it adds another exception to the blanket requirement.
>>  It should
>>          be something like
>>          "When a component of a structure of numeric sequence type or
>>          character sequence type becomes defined as a result of
>>          partially associated objects becoming defined, associated
>>          components of the same type that are components of an object
>>          of different type do not become undefined."  (This is ugly and
>>          will need some polishing, but you get the idea.)
> It would help if you supplied an example you think remains non-conforming after this change but that you think should be conforming.  Reading your proposed replacement text I am at a loss to see how the effect of it differs from that in the interp.  (If there is a difference, I'm sure I could work it out eventually, but you must have something in mind already, right?)

I had in mind the case of common block declarations resulting in partial 
and overlapping storage associations of numeric sequence type objects in 
such a way that their ultimate storage-associated components have the 
same types and kinds.  That is, defining any component wouldn't undefine 

Suppose for example that in one scoping unit there is a common block 
with two numeric sequence type objects, each having two default integer 
components.  In another there is the same common block with a default 
integer, a sequence type object with two default integer components, and 
another default integer.  Assigning to any of the numeric sequence 
objects shouldn't undefine anything.

> Cheers,

More information about the J3 mailing list