(j3.2006) (SC22WG5.4666) [ukfortran] AW: Informal WG5 ballot on new draft DTS
N.M. Maclaren
nmm1
Tue Mar 20 09:19:05 EDT 2012
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 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.
>
>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.
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.
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".
Regards,
Nick Maclaren.
More information about the J3
mailing list