(j3.2006) Question about 29113

[Van Snyder]

On Fri, 2014-10-03 at 14:52 +0900, Malcolm Cohen wrote:
> You cannot call malloc multiple times and say "oh I wanted the same
> memory back".

That's not what C_F_POINTER does.  C_F_POINTER is pointer association,
not storage allocation.  Or is there a subtle point in the wording of it
that I still don't understand?

> You get one chance to assign the result of malloc to a pointer, then
> you have to use that pointer.

I'm not as expert or experienced with C programming as others on the
committee, but I think this is OK:

double* p, q;
const size_t s = 128;
p = malloc ( s );
...
q = p;

I think this is OK too:

  type(c_loc) :: C, D
  real, pointer :: P
... ! Get a value for C from a C function
  d = c
  call c_f_pointer ( d, p )

or does that fall afoul of the "not in use by another Fortran entity"
also?  After all, C and D are Fortran entities, and their values are the
address of the same storage.

> It's the same idea here.  You get your C address back from the C
> function and then you create ONE Fortran pointer for the object;

How are these different?

module M                          module M
  use ISO_C_Binding                 use ISO_C_Binding
  type(c_loc), public :: C          real, pointer, public :: P
contains                          contains
  ...    ! Get a value for C from a C function                            ...
  real, pointer, save :: P
  call c_f_pointer ( c, p )         call c_f_pointer ( c, p )
...                               ...
module N                          module N
  real, pointer, public :: Q        real, pointer, public :: Q
contains                          contains
  ...                               ...
  use M, only: C                    use M, only: P
  call c_f_pointer ( c, q )         q => p

If the second one is prohibited too, we need to add some serious words
in 7.2.2, and that's definitely not in the integration remit.  If the
second one is permitted, it is absurd that the first is not.  They both
associate Q with the same storage as P.  Would there be a difference if
P in the first case did not have the SAVE attribute?  How about if it
were a public module variable?  That would be weird.

If module M and module N were written by different teams, working for
different companies, and neither of them got source from the other, how
are they to know?  If a diligent runtime checker detects the violation
in the first case, years after deployment, and the guy who wrote the
first version of module N has a contractual obligation to eliminate
standards violations (and nonstandard extensions), there might be
significant pointless expense involved (not to mention the significant
pointless expense in developing the diligent runtime checker).

The reason Backus gave to his management for developing Fortran was to
reduce lifetime software ownership costs.  This goes in the opposite
direction.

> any further manipulations must be based on that Fortran pointer,
> otherwise the floodgates are open to all kinds of aliasing with broken
> types.

What's broken about real?  What's new or broken about having two Fortran
pointers that have the same target?  Those floodgates were opened in
1990.  And a different floodgate involving EQUIVALENCE was opened in
1966.  This is not a new thing.

> Changing the design to do additional things is absolutely not in the
> remit of integration.  There is nothing broken here to fix.