https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92482
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org,
| |pault at gcc dot gnu.org
Summary|Possibly wrong error |BIND(C) with
|diagnostic |array-descriptor mishandled
| |for type character
--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Pre-remark: I haven't looked at your code at all, just as your remark regarding
the standard.
I think at least older versions of the standard had such a restriction to avoid
the issue with passing the "len=" argument along. (Fortran by default passes
the length as hidden argument). The solution was to use:
subroutine test(foo) bind(C)
character(kind=c_char,len=1), dimension(*) :: foo
And due to argument association, call test("Hello World"//c_null_char) still
worked/works.
Let's check F2008: "15.3.2 Interoperability of intrinsic types"
"[…] If the type is character, the length type parameter is interoperable21if
and only if its value is one."
And F2018 has the same wording in 18.3.1!
However, TS29113 and Fortran 2018 added support for array descriptors – and in
the array descriptor, one can encode the character length in elem_len (it's the
length as c_char is one-byte wide.)
Thus, a context where a descriptor is used with C binding, a len >1 or len=: is
permitted.
That's not that clearly written in the standard but implicitly at multiple
locations in Chapter 18. For instance in the following, which also lists when
an array descriptor is used:
"The source file ISO_Fortran_binding.h provides definitions and prototypes to
enable a C function to interoperate with a Fortran procedure that has a dummy
data object that is allocatable, assumed-shape, assumed-rank, pointer, or is of
type character with an assumed length." (18.1p3)
An usage example is in 18.2.3, example case (iv) which uses both an explicit
length > 1 and an assumed length.
And the elem_len is mentioned in Note 2 of 18.5.3. – And there several other
places, from which one has to collect this data.
Hence, you have encountered a left-over warning (I assume: error w/ -std=f…)
from Fortran 2003/2008 which has not been updated for Fortran 2018 – plus bugs
in the implementation of the F2018 feature.
