C_LOC and character string
in [Fortran]
|
Prev: Problems matching between FORTRAN COMMON and C struct defined in a dll
Next: Problems matching between FORTRAN COMMON and C struct defined in a ?dll
From: Richard Maine on 31 Mar 2010 12:15 Jim Xia <jimxia(a)hotmail.com> wrote: >The only comment I'd like to make here is: > in general substring of ichr, i.e. ichr(l:m), is not interoperable > with C, as Richard has commented. The relevant text of the F03 > standard is quoted as follows > > > Clause 15.2.1 > " > if the type is character, inter > 6 operability also requires that the length type parameter be omitted > or be specified by an initialization > 7 expression whose value is one." > > Strictly speaking, I'm not convienced "ichr(1:1)" is interoperable by > this restrictive definition since it is not declared as what the > standard requires. Hmm. Good point. I hadn't considered that. I'd say this was a flaw in the standard, as the quoted material is meaningless in that context. The context is defining what types and type parameter values are interoperable. This is just talking about the types - not variables or other entities of the types in question; that discussion comes later. The requirement cited above appears, as you suggest, to be talking about some presumed declaration of some presumed entity. But even if one assumes that an entity must be in evidence for a discussion of type to make sense (I already question that assumption, but let it slide for the moment), the above quote makes a further assumption that is just nonsense. A character entity doesn't have to have a declaration in the first place, so it is complete nonsense to talk about requirements on something that might not exist. The example illustrates exactly that case. There is a declaration for ichr, but there is not (and cannot be) for ichr(1:1). I claim this is a flaw in the standard. I don't off-hand recall why that exact condition was put in there. Looks like someone was trying to facilitate compile-time diagnosis of something, but the details escape me. This condition needs to be given context to make sense. My guess is that it doesn't belong in the definition of interoperability of types, but instead as a separate requirement in addition to type interoperability in some context. If it really stays where it is, then it needs supporting material for context. If it really wants to say that a character entity requires a declaration to be interoperable, it needs to say that instead of just assume that one can infer that requirement as needed for the stated requirement to make sense. (And then a note would be in order to explain that this excludes all character substrings). Anyone on the committee going to take this up as a defect? -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Reinhold Bader on 2 Apr 2010 04:07 Am 31.03.2010 18:15, schrieb Richard Maine: > > Anyone on the committee going to take this up as a defect? This is being processed as interp F03/0129. As far as I can see, the changes are reflected in the present DIS N1814. Regards >
From: Richard Maine on 2 Apr 2010 11:27
Reinhold Bader <Bader(a)lrz.de> wrote: > Am 31.03.2010 18:15, schrieb Richard Maine: > > > > > Anyone on the committee going to take this up as a defect? > > This is being processed as interp F03/0129. As far as I can see, > the changes are reflected in the present DIS N1814. So I see. I'd minorly quible with one bit of the proposed wording, but it is a minor quibble in that the meaning is obvious enough, unlike with the current wording. My quibble is that it gives a condition for the length type parameter to be interoperable, but there isn't a concept of a type parameter being interoperable - only of a type with that type parameter value. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |