Malcolm Cohen wrote:
> You are using the pointer after its sell-by date. On return from the
> procedure, the pointer is ****UNDEFINED****.
From what procedure and why exactly is it undefined?
The only troublesome line with the second version of the procedure is the
pointer assignment:
character_pointer => character_array (1)
where the LEN fields are incompatible:
CHARACTER (KIND=C_CHAR, LEN=*), POINTER :: &
character_pointer ! Has LEN>=1, not necessarily 1
CHARACTER (KIND=C_CHAR), DIMENSION (:), TARGET :: &
character_array
Though the standard may not guarantee this working, I cannot see it ever
failing on *any* compiler. If it does, so will my whole emulation of
ISO_C_BINDING and other "non-portable" codes I *need* to use...If need be,
coding a function in C to do the pointer assignment as I am intending it here
(customized for that compiler) will make the rest of my codes work unchanged.
> And when it happens, your program is sunk. I
> hope it's not going to be controlling any expensive hardware when
> that happens.
No, just some (irrelevant to the real world) number crunching. My programs are
much more portable and safer then most programs used by people in my field. And
if Fortran 95 had variable-length strings and a proper interface to C, I would
not need to resort to such tricks. Until then (or an F2x Linux compiler from
NAG), unsafe is better then other alternatives...
> Neither Richard nor I suggested making a persistent pointer
> out of the thing!
Sorry for miswording this. Yes, your (good) advice was for a different matter.
I just borrowed the trick...
Best,
Aleksandar
|