[J3] CFI_establish and elem_len for zero-length character strings and empty types/structs

Fri Aug 13 02:22:11 UTC 2021

I rescued this from my spam filter, apologies for bringing it up again.

To be *interoperable* a character variable must indeed always have a length of one. That is what the standard says. It is no good quoting some text and cutting out the bit where it says “A named scalar Fortran variable is interoperable if and only if its type and type parameters are interoperable,”...

That requirement is absolute, and in conjunction with

“If the type is character, the length type parameter is interoperable if and only if its value is one.”

And with the not-assumed-or-nonconstant requirement that you quoted, it is perfectly clear that an interoperable character variable is required to have the value one for its length type parameter.

Oh, and the latter is not a “generic requirement that may be relaxed”, it is an absolute statement “if and only if”.

> So far I was under the impression that also, e.g., len=5 is permitted
in this case (since Fortran 2008).

Last time I checked, 5 was not equal to one. So no, that is not the case!

> Likewise, I was under impression that len != 1 is permitted
for len=* and len=: (and as const expr via 18.3.4 (quoted above)) in:

Well, * is not permitted for an interoperable variable according to the very text you quoted, “not assumed”. And the ALLOCATABLE and POINTER attributes are also forbidden for interoperable variables, so len=: is likewise unavailable.

> In any case, I have read it such that Fortran 2003 only permitted len=1
while Fortran 2008 (and 2018) permit in _some_ cases other lengths.

Fortran 2008 did not make any additional C interoperability other than the addition of C_SIZEOF and some extra flexibility to C_LOC. There were some wording changes between Fortran 2003 as published and Fortran 2008, because the initial wording in F2003 was too sloppy. The wording defects were corrected in Technical Corrigenda to F2003.

Both Fortran 2008 and 2018 require len=1 for interoperable variables, no ifs buts or maybes. This is nailed down by absolute statements, not ones that say “unless otherwise specified elsewhere” or similar weasel words.

Fortran 2018 (but not 2008) does add “further C interoperability”, which permits a BIND(C) procedure to have an argument that is *not* interoperable, as long as it satisfies certain conditions. This is in C1554 which you quoted, which requires that the dummy variables be “interoperable [or] assumed-shape etc.” (The “or” is at the end of the long list of alternative conditions that may be satisfied.) As that wording implies, such arguments are not themselves “interoperable”, but they are now allowed, and are handled by the C descriptor passing mechanism.

Basically, “interoperable” means that the Fortran thing and the C thing are “the same” in some fundamental sense.

The C descriptor mechanism provides the capability for a C procedure to handle Fortran things that do not have a direct analogue in C, and which are not therefore in themselves interoperable.

Cheers,

-- 

..............Malcolm Cohen, NAG Oxford/Tokyo.

From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Tobias Burnus via J3
Sent: Friday, July 23, 2021 4:38 PM
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Tobias Burnus <burnus at net-b.de>
Subject: Re: [J3] CFI_establish and elem_len for zero-length character strings and empty types/structs

I wrote in reply to Malcolm:
> You wrote that "Fortran character strings of length zero are not interoperable". Can you pinpoint this in the standard for arguments passed as CFI array descriptor? From F2018's 18.3.6 (5) bullets (2)+(3) and 18.3.6 (6) it sounds as if it should be valid. But I likely missed some fineprint elsewhere.

On 22.07.21 20:01, Robert Corbett via J3 wrote:
> Paragraph 1 of Subclause 18.3.1
> of 18-007r1 states
>
> If the type is character, the length
> type parameter is interoperable
> if and only if its value is one.

I do know about this – but my impression was/is that this generic
requirement is relaxed for some use cases. (All quotes form 18-007r1.)

For instance, in "18.3.4 Interoperability of scalar variables"

"A named scalar Fortran variable is interoperable ... if it is
of type character its length is not assumed or declared by
an expression that is not a constant expression."

If I understood _you_ correctly, a variable or dummy argument
might have a constant length (per 18.3.4/5 and C1554/18.3.6)
but _due to 18.3.1_ the constant must _always_ be one?

So far I was under the impression that also, e.g., len=5 is permitted
in this case (since Fortran 2008).

Likewise, I was under impression that len != 1 is permitted
for len=* and len=: (and as const expr via 18.3.4 (quoted above)) in:

"C1554 If proc-language-binding-spec is specified for a procedure,
each of its dummy arguments shall be an interoperable
procedure (18.3.6) or a variable that is interoperable
(18.3.4, 18.3.5), assumed-shape, assumed-rank, assumed-type,
of type CHARACTER with assumed length, or that has
the ALLOCATABLE or POINTER attribute."

where 18.3.6 adds some more restrictions, also depending whether
the VALUE attribute is present.

* * *

If indeed only len=1 is permitted, then it should be made more clear
in the standard. (NB: The constant length in 18.3.{4,5} appeared first in
Fortran 2008, in Fortran 2003 only the 18.3.1 wording appeared.)

In any case, I have read it such that Fortran 2003 only permitted len=1
while Fortran 2008 (and 2018) permit in _some_ cases other lengths.

* * *

Thus:

If only len=1 is permitted, then I find the 2008/2018 wording very confusing.

On the other hand, if len != 1 is sometimes permitted, then it is
still unclear to me what makes len=0 invalid for CFI_cdesc_t.
At least I do not see this requirement in 18.3.6 (5) + (6)
nor elsewhere in the spec.

Tobias

Disclaimer

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: 30 St. Giles, Oxford, OX1 3LE, United Kingdom. Please see our Privacy Notice <https://www.nag.co.uk/content/privacy-notice>  for information on how we process personal data and for details of how to stop or limit communications from us.

This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210813/0e06e1e0/attachment.htm>