(j3.2006) (SC22WG5.4667) [ukfortran] AW: Informal WG5 ballot on new draft DTS

[Bill Long]

On 3/20/12 8:19 AM, N.M. Maclaren wrote:
> On Mar 20 2012, N.M. Maclaren wrote:
>> On Mar 19 2012, Bader, Reinhold wrote:
>>> Malcolm Cohen wrote
>>>> 8.4, Note 8.11 [p29] Do we really have to say "C programmers should
>>>> note"? In any case it is far too weakly worded (Reinhold's version
>>>> does not really improve this), here is my suggestion: "A C function
>>>> that modifies a C descriptor other than as permitted by this
>>>> Technical Specification will cause undefined behaviour." BTW re

My main interest is whether we all agree with the  wording change above 
(apart from spelling).


>>>> Reinhold's version - pointer arithmetic beyond the limits of an
>>>> object is already undefined behaviour in C, so I think we need not
>>>> (and should not) say anything about that.
>>>
>>> I was targetting the case of calculating a perfectly valid C address
>>> which happens to not be part of the described Fortran object e.g., in
>>> the case of a discontiguous array. Since the /base_addr/ is exposed,
>>> there is a quite good chance of this happening to the unsuspecting C
>>> programmer.
>>

This is a different issue than what is covered by the new wording above. 
  Without any modification of any C descriptor a user could (but should 
not) add an offset to a copy of the base address in a descriptor that 
becomes a pointer to a data entity (memory location) that is not part of 
the described object.  This would not happen in a Fortran procedure, but 
given the "Wild Wild West" nature of C pointers, it could in a C 
function. I think the original wording was intended to cover this case. 
  The calling Fortran procedure might have made optimizations based on 
the assumption that the (now wrongly accessed in the C function) 
variable would not change during execution of the C function.


>> As the person to blame for perpetrating that vague evasion, let me try
>> to explain why I did it :-(
>
> Oops. That may still be confusing. I was trying to address Reinhold's
> concern, only more generally. It isn't JUST the modification of
> descriptors in other ways, but the creating of perfectly valid C pointers
> and then creating a new descriptor from them. If this ends up creating
> two Fortran objects that the Fortran compiler 'knows' are distinct but
> aren't, chaos will sometimes ensue.
>

Unless this second object is accessible in Fortran by, for example, 
being associated with an argument in a call to a Fortran procedure, the 
newly created descriptor could be harmless.   But I think the descriptor 
issue is an extra complication here - equally bad mischief is possible 
with ordinary pointers.


> For example, creating a logical descriptor from one passed as a complex
> descriptor. That's quite legal in C but, because EQUIVALENCE is forbidden
> for arguments, optimising compilers may assume that it can't happen in
> that way.
>

As long as the new descriptor is localized to the C function, the 
compiler that matters is the C compiler, which is not that optimizing.

> An even worse one is to use the C interface to produce the class of
> intrinsic that Fortran lacks - i.e. a variable-semantics one (like array
> sections) rather than value-semantics. That would enable someone to
> provide the originally requested facility of creating a slanted array
> section, such as a diagonal.
>
> I am certain that we need SOME way of saying "don't go there".
>

Agreed.  We just need to agree where "there" is.

Cheers,
Bill


>
> Regards,
> Nick Maclaren.
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101