On Wed, Jan 22, 2020 at 04:43:49PM +0100, Tobias Burnus wrote:
> Hi Steve,
>
> On 1/22/20 4:02 PM, Steve Kargl wrote:
> > On Wed, Jan 22, 2020 at 11:59:12AM +0100, Tobias Burnus wrote:
> >> And, additionally, about missing diagnostic related to (2) bind(c) and
> >> kind=4,
> > Are you sure there is a missing diagnostic? You need to
> > add -Wc-binding-type or -Wall to your command line.
>
> The problem with the ISO C warnings for character is that they are not
> based on the KIND value but whether the variable comes from the
> ISO_C_BINDING module or not.
>
> Namely, for kind=1 and kind=4 you get the warning you have shown while
> for kind=c_char and kind=c_int32_t you don't. (If you use "integer,
> parameter :: mykind = c_char", the result is the same as for c_char as
> this property is inherited.)
>
> Numerically, 1 and c_char are the same – as are 4 and c_int32_t. I think
> one *can* warn for using kind=1 as this is bad style (= assumption that
> c_char is the same as "1" and the same as the default-kind character).
>
> But "kind=4" is as bad as "kind=c_int32_t"! — And as noted in the PR,
> using c_char and c_int32_t (!) will give a "character(kind=1)" (note the
> kind=1!) dummy argument while kind=1 and kind=4 will give
> "character(kind={1 or 4})[1:1]" (= ARRAY_TYPE).
>
> That's complete nonsense and in some cases it does not even depend on
> whether that's a BIND(C) procedure or not!
>
Not that I disagree with you, but this is what happens when
UTF-8 (kind=4) is wedged on top of ISO C Binding (kind=c_char),
which is wedged on top of a Fortran 95 compiler. Supposedly, one
can use attr.is_c_interop and attr.is_iso_c to determine if something
is interoperable (if it is consistently set) and if it is from
the ISO C Binding module.
The solution is to use unique kind values forall types (reserve
1-9 for integer, 11-19 for real, 21-29 for character, etc). Then
one simply needs to define a storage association mapping.
--
Steve
