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

[N.M. Maclaren]

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 :-(

The rules on pointer arithmetic are complicated beyond the belief of
any sane person and, worse, rapidly descend into its morass of behaviour
that is simultaneously explicitly defined and explicitly undefined.
Even worse, those 'features' are often standard practice, not least
because C++ depends on some of them.

For example, it is possible to have a valid pointer that does not point
to an object, in several interesting and semantically different ways.
That's clearly defined.

It is also possible to use arithmetic to derive a pointer to one object
from a pointer to a completely unrelated object.  While that appears to
be undefined, it can be (and is) done by using a sequence of steps, all
of which are clearly defined.

The point is that such tricks won't cause trouble to Fortran, directly,
but might cause havoc with its optimisation.  They would have caused
some trouble to C90 for the same reason, but recent C standards and C++
have taken the decision that they do not permit optimisation of the
traditional form that Fortran compilers use.

We may well be able to do better, but I am positive that we need the
wording. 

Regards,
Nick Maclaren.