namelist group name and save attribute

[Steven G. Kargl]

A bug report was submitted to the gcc bugzilla stating that
the following code should produce an error:

program foo
namelist /i/ ii
save i
end program foo

because the namelist group name is in a saved-entity-list.

I've been unable to find a provision in the F2003 standard
that prohibits the above. The only interpretation that
comes to mind is that each namelist-group-object is given
the attribute. So, in the above ii would be saved. Is
this the correct interpretation?

--
steve

[Richard Maine]

No. It should produce an error message. You can't find a prohibition
because it is built into the syntax instead of prohibitted in words. The
bnf for the SAVE statement says that it has a saved-entity-list, where a
saved entity (R544) is object-name, proc-pointer-name, or
/common-block-name/.

I didn't bother to actually track down proc-pointer-name because it
seems pretty obvious that better not fit (if it does, then that would
hav eto be an error in the standard, but I rather doubt it fits). It is
almost as obvious to be that object-name had better be the name of an
object, but I suppose that one just possibly might have slipped through
somewhere... Nope. Looks fine. See the bnf for object-name (R505), which
comes with the obvious constraint (C505) The object-name shall be the
name of a data object.

So not only "should" it produce an error message, it is a constraint
violation, which puts in in the set of things that the compiler is
required to be able to diagnose ("required to" being stronger than
"should").

I suppose another interpretation is that the SAVE statement effectively
declares a local variable named i, which is what it would do without the
namelist statement. But that runs into another prohibition, which I
won't bother to track down citations for - the prohibition against
having two different class 1 entities with the same name in the same
scope.

I'm guessing that you overlooked that "object" has a precise meaning in
Fortran. I'll let you go track the references for that, but I assure you
that a namelist-group isn't one. "Object" isn't like "entity" which is
just standard speak for "thing". I personally objected to the standard's
definition on "entity" in the glossary, because it tries to sound like
it actually means something. Instead, that list in the glossary is
nothing but a spew of every kind of thing that people could think of
that might be relevant to any usage of "entity" in the standard. There
is no coherence of meaning other than that; "entity" in the standard
really just does mean "thing - anything". But "object" is short for
"data object" and is much more precise. (It also has no particular
connection to "object-oriented").

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

[Steven G. Kargl]

Thanks for the thorough answer. I started tracking through the bnf
after I posted my question, and I came to the conclusion that the
code was indeed invalid. I had already fixed gfortran to emit an
error, but wanted to double-check that I did not miss some dusty
corner of the standard.

Unfortunately, I also found that gfortran has interpreted something
like

integer i, j, k
namelist /cmd/ i, j, k
save cmd

to mean

integer i, j, k
namelist /cmd/ i, j, k
save i, j, k

:-(

Now, I have to decide whether I should sweep this under the GNU
Fortran extension umbrella or accept the possible fall out of
breaking people's codes.

--
steve

[glen herrmannsfeldt]

Richard Maine <nos...@see.signature> wrote:
> Steven G. Kargl <s...@REMOVEtroutmask.apl.washington.edu> wrote:

>> A bug report was submitted to the gcc bugzilla stating that
>> the following code should produce an error:

>> program foo
>> namelist /i/ ii
>> save i
>> end program foo

(snip)

(snip)

> I suppose another interpretation is that the SAVE statement effectively
> declares a local variable named i, which is what it would do without the
> namelist statement. But that runs into another prohibition, which I
> won't bother to track down citations for - the prohibition against
> having two different class 1 entities with the same name in the same
> scope.

I wondered about that one, too.

I had a small program with NAMELIST, so I tried instead adding

integer i

or

external i

both of which generated an error message.

Otherwise, it seems an interesting extension, adding the SAVE
attribute to all variables in the NAMELIST.

-- glen

[Ron Shepard]

In article <1k9vag1.6bwz3pw1bjyN%nos...@see.signature>,

nos...@see.signature (Richard Maine) wrote:

> Steven G. Kargl <s...@REMOVEtroutmask.apl.washington.edu> wrote:
>
> > A bug report was submitted to the gcc bugzilla stating that
> > the following code should produce an error:
> >
> > program foo
> > namelist /i/ ii
> > save i
> > end program foo
> >

[...]

> I suppose another interpretation is that the SAVE statement effectively
> declares a local variable named i, which is what it would do without the
> namelist statement. But that runs into another prohibition, which I
> won't bother to track down citations for - the prohibition against
> having two different class 1 entities with the same name in the same
> scope.

If an IMPLICIT NONE were added, then this interpretation of the SAVE
statement should trigger errors from the undeclared variable.

Along this same line of thought, if "ii" were some entity that cannot be
saved (e.g. dummy argument, module variable, common block variable, host
association variable), then the first interpretation of the SAVE
statement should trigger the corresponding error.

All in all, I think if I typed the above by mistake, I would rather see
the error statement telling me so rather than having it mean either of
the above extensions. If I did want to save the variables in the
namelist, then I would rather that it must be done in the usual way
rather than "indirectly" with this extension.

BTW, just to show that I'm more or less consistent on this issue, I also
did not like the "save on initialization" semantics that was added with
f90. I would have preferred for the compiler to warn me that I needed
the save attribute for those variables.

$.02 -Ron Shepard