deferred type parameters, again
steve
stumbled upon the following code:
program test
character(len=:) fmt
allocate(character(len=:) :: fmt)
end program test
This certainly looks to be invalid, but under Sec. 6.3.1
I can't find a prohibition or any clear guidance on how
the above would be interpreted.
In addition, can someone shed some light on this passage
from the F2003 standard, 6.3.1, page 111:
When an ALLOCATE statement having a type-spec is executed,
any type-param-values in the type-spec specify the type
parameters. If the value specified for a type parameter
differs from a corresponding nondeferred value specified
in the declaration of any of the allocate-objects then an
error condition occurs.
In particular, I'm interested in examples of 2nd sentence.
Richard Maine
> In developing a testcase for the gfortran testsuite, I
> stumbled upon the following code:
>
> program test
> character(len=:) fmt
> allocate(character(len=:) :: fmt)
> end program test
>
> This certainly looks to be invalid, but under Sec. 6.3.1
> I can't find a prohibition or any clear guidance on how
> the above would be interpreted.
I'm feeling to lazy to go look for a prohibition right now. I'd sort of
expect to find one somewhere and would consider it a minor bug in the
standard if it isn't explicitly prohibited. I would say that it was
prohibited anyway, if only because there is a general thing somewhere
way up front that prohibits things where the standard does not establish
an interpretation. The standard certainly doesn't establish an
interpretation of what this would mean for the length. But usually we
prefer to make such prohibitions explicit instead of falling back on
that general thing.
Oh, and I assume your omission of the allocatable attribute is
accidental and not the real subject of the question. Otherwise, it is
much simpler and invalid for multiple reasons (deferred type parameter
on something that isn't pointer, allocatable, or dummy; allocation of
something that isn't pointer or allocatable).
>
> In addition, can someone shed some light on this passage
> from the F2003 standard, 6.3.1, page 111:
>
> When an ALLOCATE statement having a type-spec is executed,
> any type-param-values in the type-spec specify the type
> parameters. If the value specified for a type parameter
> differs from a corresponding nondeferred value specified
> in the declaration of any of the allocate-objects then an
> error condition occurs.
>
> In particular, I'm interested in examples of 2nd sentence.
character(len=3), allocatable :: c
...
allocate(character(len=6):: c)
If I recall correctly, there is a bit if inconsistency in that an
allocatable array is required to have deferred shape, but I don't think
an allocatable variable is required to have deferred length type
parameters. (It would be hard to see how this could come up if there
were such a requirement; also, such a requirement would have been
incompatible with f95, which doesn't have deferred type parameters).
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
steve
> steve <kar...@comcast.net> wrote:
> > In developing a testcase for the gfortran testsuite, I
> > stumbled upon the following code:
>
> > program test
> > character(len=:) fmt
> > allocate(character(len=:) :: fmt)
> > end program test
>
> > This certainly looks to be invalid, but under Sec. 6.3.1
> > I can't find a prohibition or any clear guidance on how
> > the above would be interpreted.
>
> I'm feeling to lazy to go look for a prohibition right now. I'd sort of
> expect to find one somewhere and would consider it a minor bug in the
> standard if it isn't explicitly prohibited.
Well, I can't find a prohibition. The number constraints in 6.3.1
seem to miss this case and the surrounding text does not give
a prohibition. There may very well be one, but I can't find it.
> I would say that it was
> prohibited anyway, if only because there is a general thing somewhere
> way up front that prohibits things where the standard does not establish
> an interpretation. The standard certainly doesn't establish an
> interpretation of what this would mean for the length.
From a common-sense standpoint, I had come to essentially this
conclusion.
> But usually we
> prefer to make such prohibitions explicit instead of falling back on
> that general thing.
>
> Oh, and I assume your omission of the allocatable attribute is
> accidental and not the real subject of the question. Otherwise, it is
> much simpler and invalid for multiple reasons (deferred type parameter
> on something that isn't pointer, allocatable, or dummy; allocation of
> something that isn't pointer or allocatable).
Yes. The declaration of fmt should have included ALLOCATABLE.
>
> > In addition, can someone shed some light on this passage
> > from the F2003 standard, 6.3.1, page 111:
>
> > When an ALLOCATE statement having a type-spec is executed,
> > any type-param-values in the type-spec specify the type
> > parameters. If the value specified for a type parameter
> > differs from a corresponding nondeferred value specified
> > in the declaration of any of the allocate-objects then an
> > error condition occurs.
>
> > In particular, I'm interested in examples of 2nd sentence.
>
> character(len=3), allocatable :: c
> ...
> allocate(character(len=6):: c)
>
> If I recall correctly, there is a bit if inconsistency in that an
> allocatable array is required to have deferred shape, but I don't think
> an allocatable variable is required to have deferred length type
> parameters. (It would be hard to see how this could come up if there
> were such a requirement; also, such a requirement would have been
> incompatible with f95, which doesn't have deferred type parameters).
Thanks for the comment. I had assume (may be correctly) that the
above was prohibited by C624. But on closer inspect C624 discuss
'type compatible' which I may have misinterpreted.
--
steve
Richard Maine
> On Jul 1, 12:38 pm, nos...@see.signature (Richard Maine) wrote:
> > steve <kar...@comcast.net> wrote:
> > > In developing a testcase for the gfortran testsuite, I
> > > stumbled upon the following code:
> >
> > > program test
> > > character(len=:) fmt
> > > allocate(character(len=:) :: fmt)
> > > end program test
> >
> > > This certainly looks to be invalid, but under Sec. 6.3.1
> > > I can't find a prohibition or any clear guidance on how
> > > the above would be interpreted.
> >
> > I'm feeling to lazy to go look for a prohibition right now. I'd sort of
> > expect to find one somewhere and would consider it a minor bug in the
> > standard if it isn't explicitly prohibited.
>
> Well, I can't find a prohibition. The number constraints in 6.3.1
> seem to miss this case and the surrounding text does not give
> a prohibition. There may very well be one, but I can't find it.
Ok. Went and looked. Found it, but it is a bit far away from where you
were probably looking. That's largely because it isn't specific to the
ALLOCATE statement. It is a much more general restriction. See C403
" A colon may be used as a type-param-value only in the declaration of
an entity or component that has the POINTER or ALLOCATABLE attribute."
If you looked at this constraint at all, you might have focused on the
POINTER and ALLOCATABLE bits, but the "declaration of" bit is also
important. The ALLOCATE statement is not a declaration. So you can't put
the (len=:) in an allocate statement at all.
> > > In addition, can someone shed some light on this passage
> > > from the F2003 standard, 6.3.1, page 111:
> >
> > > When an ALLOCATE statement having a type-spec is executed,
> > > any type-param-values in the type-spec specify the type
> > > parameters. If the value specified for a type parameter
> > > differs from a corresponding nondeferred value specified
> > > in the declaration of any of the allocate-objects then an
> > > error condition occurs.
> >
> > > In particular, I'm interested in examples of 2nd sentence.
> >
> > character(len=3), allocatable :: c
> > ...
> > allocate(character(len=6):: c)
> >
> > If I recall correctly, there is a bit if inconsistency in that an
> > allocatable array is required to have deferred shape, but I don't think
> > an allocatable variable is required to have deferred length type
> > parameters. (It would be hard to see how this could come up if there
> > were such a requirement; also, such a requirement would have been
> > incompatible with f95, which doesn't have deferred type parameters).
>
> Thanks for the comment. I had assume (may be correctly) that the
> above was prohibited by C624. But on closer inspect C624 discuss
> 'type compatible' which I may have misinterpreted.
Type compatible is defined in 5.1.1.2. That's perhaps a bit of an odd
place, as that is the section on the CLASS type specifier and type
compatibility applies to all types. It just happens that it is
nontrivial only for things declared with CLASS. If there are no CLASS
declarations in sight, then "type compatible" just means "same type". It
has nothing to do with type parameters - only types. So here, it just
means type character. There is a concept of TKR (type, kind, and rank)
compatibility also defined in 5.1.1.2. That one does have to do with
some type parameters, but not length ones, and in any case it isn't what
C624 specifies.
So no, C624 does not prohibit that. The passage that you asked about is
what prohibits it. That restriction is not a constraint because length
parameter specifications in ALLOCATE statements are not in general
required to be computable at compile time (add the usual caveat about
that not being the way that the standard says it... but that's still the
reason).
steve
Once again thanks for sharing your expertise. gfortran's source
code (not including the runtime library) is 128 KLOC. I've started
adding what some might consider to be trite comments. For example,
the 5 lines of code that now check C403 is prefaced with /* C403:
not a declaration. */
REMOVE:kargl[206] gfc4x -c t.f90
t.f90:4.12:
allocate(character(:) :: fmt)
1
Error: Type-spec at (1) cannot contain a deferred type parameter
--
steve