(j3.2006) Interoperable dummy arguments

[Van Snyder]

Erik can correct me if I misunderstand his question, but I think he's
referring to the relationship between C1555 and 18.3.5p1, wherein a
variable of type character is specified not to be interoperable if its
length is assumed.  18.3.5 is concerned with interoperability of scalar
variables, not interoperable types.  Interoperable intrinsic types are
listed in Table 18.2 in subclause 18.3.2.

C1554 says a dummy argument has to be interoperable and cites 18.3.5,
which says character scalars aren't interoperable if they have assumed
length, and then goes on to allow characters with assumed length.

18.3.6 also says character arrays aren't interoperable if they have
assumed length.

I agree it's confusing.

Is it still correct to say that a character scalar variable or array
with assumed length is not interoperable?

On Thu, 2017-05-25 at 09:20 +0900, Malcolm Cohen wrote:
> Hi Erik,
> 
> No you are not right, because C1555 makes no mention whatsoever of length
> type parameters.  A CHARACTER(*) variable is of interoperable type, but not
> of interoperable type parameters.
> 
> Discussion:
> C1554 provides an overall constraint with a list of things that a dummy
> variable of a BIND(C) procedure needs to be.  These are combined with "or",
> which loses the type requirements for e.g. assumed-shape, allocatable and
> pointer arguments.  The purpose of C1555 is to maintain the type
> requirements for e.g. assumed-shape etc.
> 
> I agree that it is a bit confusing.  It might be worth us spending some time
> trying to wordsmith those two constraints so that the structure requirements
> are not mixed up with the type requirements.  But we would need to be
> careful not to break it...
> 
> Actually, looking at C1555 I think it is already slightly "broken", in that
> I think it should be requiring interoperable kind type parameters.  That is,
> it clearly disallows a derived-type that is not a BIND(C) type, but it seems
> to allow a REAL(k) type where k selects a representation method that does
> not correspond to any C type.  (The semantics of that would be
> contradictory, so it cannot actually be conforming, but the standard does
> not seem to get it right.  Unless there are words elsewhere to sort that
> out.)  If this analysis is correct, some attention really should be given to
> those constraints.
> 
> Cheers,