[patch, fortran] PR30481 Accepts namelist-group object with assumed character length
Brooks Moses
brooks.moses@codesourcery.com
Tue Jan 23 09:54:00 GMT 2007
Tobias Burnus wrote:
> Brooks Moses wrote:
>> I seem to recall a discussion of this on comp.lang.fortran recently,
>> where it was mentioned that this restriction was a F95 thing that was
>> relaxed in F2003. Unfortunately, I can't seem to find the comment
>> again, but it looks to me like the language in the standard does relax
>> the restriction.
>
> The thread which lead to the bug report is at
> http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/75b797b2d4257f74
> but there I cannot find anything about a relaxation in Fortran 2003.
Thanks very much for tracking that down!
> And Fortran 2003:
>
> "5.4 NAMELIST statement"
> "C574 (R553) A namelist-group-object shall not be an assumed-size array."
> "A namelist group object shall either be accessed by use or host association or
> shall have its type, type parameters, and shape specified by previous
> specification statements or the procedure heading in the same scoping unit or
> by the implicit typing rules in effect for the scoping unit. If a namelist
> group object is typed by the implicit typing rules, its appearance in any
> subsequent type declaration statement shall confirm the implied type and type
> parameters."
>
> I have actually some problems in fully understanding the Fortran 2003 text.
How I'd look at it is to eliminate all the parts that are irrelevant to
this case, and it actually does help sometimes to actually write it out
-- think of it as manually evaluating the parts of the "and" and "or"
clauses that can be constant-folded. :)
This isn't accessed by use or host association, so that's out. The type
and shape are irrelevant to this, so we can ignore those, leaving only
type parameters (of which character length is one). Implicit typing
rules don't affect type parameters, so that clause and the last sentence
are irrelevant. That leaves:
"A namelist group object shall ... or have its ... type parameters ...
specified by previous specification statements or the procedure heading
in the same scoping unit...."
That leaves us with the question of whether the "LEN=*" in the
specification statement counts as specifying the type parameter or not.
And, in this case, I am personally not at all sure, so that leaves me no
better off than before I started writing all this analysis.
> Note that Richard Main wrote in that thread:
> "I'll also note that I don't see any big reason why the standard
> couldn't be extended to allow this in the future. When Namelist was
> added to the standard (in f90), it was done in a pretty conservative and
> minimalist fashion in several regards. In my personal judgement, this
> particular restriction was probably overkill in that I wouldn't expect
> it to be hard to implement in
> most compilers."
>
> Given that he knows the standard pretty well, it indicates that it might
> indeed be still not allowed in F2003.
Indeed -- that's how I read it, and I'll defer to his judgement. This
is certainly the bit of discussion that I was remembering earlier, but
apparently I misremembered the conclusion that he drew.
>> If that's true, I'd suggest that this should be a -std=f95 thing, not
> an absolute error.
>
> If it is true, then yes. Otherwise: Explicit error or legacy?
Not legacy; we have no indication that any legacy codes use this
feature, so far as I know.
If I believed in using GNU extensions to do useful things, such that we
were continuing the G77 tradition of defining a "GNU Fortran" language
that was "better" than the standardized form, I'd consider this a strong
candidate for such an extension. However, we seem to be leaning much
more towards encouraging the use of portable code and not adding new
extensions, so it probably shouldn't be a GNU extension either.
Thus, an absolute error it is, I'd say.
Again, thank you muchly for the detailed answer to my rather vague comment!
- Brooks
More information about the Fortran
mailing list