(j3.2006) (SC22WG5.4668) [ukfortran] AW: Informal WG5 ballot on new draft DTS
Tue Mar 20 12:22:22 EDT 2012
On Mar 20 2012, Bill Long wrote:
>>> 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.
Not really. I am thinking of Fortran creating a (say) complex object
with the target attribute, passing it to C, and that calling Fortran
with a logical argument with the pointer attribute, in a context where
the original object is visible. Because a logical pointer can't refer
to a complex target in Fortran (can it?), it could optimise on the basis
of that assumption. Bang!
>> 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.
Yes. That's not the problem.
More information about the J3