(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".

Nick Maclaren.

More information about the J3 mailing list