(j3.2006) (SC22WG5.4669) AW: [ukfortran] AW: Informal WG5 ballot on new draft DTS
Tue Mar 20 12:55:01 EDT 2012
> >>>> 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
would do the job?
More information about the J3