------- Comment #4 from brtnfld at hdfgroup dot org 2008-12-15 16:52 -------
>
> In any case: I tried ifort, g95, NAG f95, gfortran, and sunf95 - of these only
> "ifort" allows it (even with all checking enabled - thus presumably only by
> accident and not on purpose).
>
> Thus I wonder whether simply using the following "evil" workaround is better
> than patching the compiler:
>
> f_ptr = C_LOC(X(1:1))
>
> That works with gfortran, ifort, g95 and NAG f95. (It fails with sunf95, whose
> C interoperability is a bit shaky in general.) As the string should be
> contiguous in memory it should be the OK. Additionally, that is also what one
> would do in C:
>
> char X[40];
> ptr = &X; // or equivalently: ptr = &X[0];
as you said using C_LOC(X(1:1)) works fine and that is what I ended up doing.
BTW, ifort 11 and pgf90 7.2-1 also allow C_LOC(X). But, while using X(1:1)
works fine in general, if I try to use it in a derived type gfortan (all
versions) it fails to compile with an internal error,
Internal Error at (1):
Unexpected expression reference type in gfc_iso_c_func_interface
for example:
MODULE modtest
USE ISO_C_BINDING
TYPE test
CHARACTER(LEN=2), DIMENSION(1:2) :: c
INTEGER(C_INT) :: i
END TYPE test
END MODULE modtest
PROGRAM main
USE ISO_C_BINDING
USE modtest
TYPE(test), TARGET :: chrScalar
TYPE(C_PTR) :: f_ptr
f_ptr = c_loc(chrScalar%c(1)(1:1))
END PROGRAM main
g95, ifort, and pgf90 all compile it. But this is maybe a separate issue.
Since there is a work around (in most cases) and according to the standard a
character must be length = 1 for X, I'm willing to withdrawal the request for
the enhancement.
As for the issue with the generic interface; none of the compilers can compile
the code so generic resolution does not seem to have been extended to allow
this behavior and it seems the requirement of matching Type, Kind and Rank
trumps all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36771
