(j3.2006) (SC22WG5.4667) [ukfortran] AW: Informal WG5 ballot on new draft DTS
Tue Mar 20 11:19:00 EDT 2012
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
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.
> Nick Maclaren.
> J3 mailing list
> J3 at j3-fortran.org
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
More information about the J3