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

[Van Snyder]

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 
anything.

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,
>