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

[Bader, Reinhold]

[...]
> 
> 
> >>>> 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.
> >>
> 
> 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.

It could be understood to do this by someone who was involved writing the TS :-)


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

I think it is not only an optimization issue. Overwriting data via a dereference
to an incorrectly computed offset is technically possible within C, but should 
be banned for at least such entities created within Fortran. Actually, some 
additional normative text may be required. Perhaps something like

"References and definitions to an entity accessed via an address computed
 from the /base_addr/ member of a C descriptor are valid if and only if this
 address can also be computed by invocation of CFI_address with that descriptor
 or another descriptor created as a subobject of it as its /dv/ argument, and
the type to which it is cast is consistent with the /type/ member of that
descriptor argument."

would do the job?


Regards
Reinhold