F95+ Standard question: Interleaved DATA + default initialization
Tobias Burnus
I am seeking a second opinion regarding the validity of the following
code. It consists of a derived type, where one component is has a
default initializer. The other component is initialized via DATA.
Two of the tested compilers accept the code and have the 'right
value' (DATA + default initializer); two others accept it, but only
the DATA initialization is effective, one compiler has an internal
compiler error, and four compilers reject the code with an error
message (judging from the message, they are based on the same code).
The relevant parts of the standard (my quotes are from F2008) seem to
be:
"If a nonpointer object has default initialization, it shall not
appear in a
data-stmt-object-list." (5.4.7 DATA statement)
"5.2.3 Initialization":
"Explicit initialization alternatively may be specified in a DATA
statement
unless the variable is of a derived type for which default
initialization is
specified."
"A variable, or part of a variable, shall not be explicitly
initialized more
than once in a program."
At least the last part does not apply; I think also the other parts do
not apply, which would make the code valid. However, like always when
reading the standard, misreading or missing paragraphs can easily
happen.
The code in question (from gfortran's PR 49278; gfortran gives an
internal error):
module oad_active
implicit none
type active
integer :: v
integer :: d = 42
end type
end module
module tots_c
use oad_active
implicit none
type(active), save :: trlkold
data trlkold%v /100/
end module
program foo
use tots_c
implicit none
if (trlkold%d /= 42) stop 'ERROR d /= 42'
if (trlkold%v /= 100) stop 'ERROR v /= 100'
end program foo
Tobias
robin
news:a0bd6452-708a-4802...@28g2000yqu.googlegroups.com...
You are not initializing anything more than once,
so the above extracts do not apply.
I may be wrong, but I don't see anything wrong with the code.
Richard Maine
> I am seeking a second opinion regarding the validity of the following
> code. It consists of a derived type, where one component is has a
> default initializer. The other component is initialized via DATA.
...
> The relevant parts of the standard (my quotes are from F2008) seem to
> be:
>
> "If a nonpointer object has default initialization, it shall not
> appear in a
> data-stmt-object-list." (5.4.7 DATA statement)
>
> "5.2.3 Initialization":
> "Explicit initialization alternatively may be specified in a DATA
> statement
> unless the variable is of a derived type for which default
> initialization is
> specified."
> "A variable, or part of a variable, shall not be explicitly
> initialized more
> than once in a program."
Good thing I didn't rely on my memory. I didn't recall those
restrictions at all (except for the last one, which is different). In
fact, I thought I recalled something that would seem to contradict them.
Hmm. Yep. In 4.5.3.4 of f2003 we have "Explicit initialization in a type
declaration statement (5.1) overrides default initialization (see Note
4.33)".
Maybe the "in a type declaration statement" might be the out here.
There is a horribly vague bit in the standard in 5.2 of f2003 saying
"The combination of attributes that may be specified for any entity is
subject to the same restrictions as for type declaration statements
regardless of the method of specification." I've long despised the
vagueness of that bit, which is largely a consequence of the standard's
tendency to specify too many things in terms of syntax. That particular
bit is a "hack" that basically says, in my words, "You know all those
restrictions expressed in terms of syntax? Well they aren't actually
about the syntax." I believe there was an attempt to fix some of that
mess in f2008; I've never reviewed it in detail to see. I'll leave such
f2008 questions to others; I just can't get up the enthusiasm for
digging that deeply into f2008 when I don't have any f2003 compilers.
Anyway, the "in a type declaration statement" might be intended to
override that vague bit and say that "we really do mean just in that
particular syntax for this case." I'd hesitate to say for sure. There is
at least some reason to think so. DATA statements are "special" in that
they can partly initialize a variable, which indeed is exactly the
subject problem area. (DATA statements are "special" in other ways as
well).
> At least the last part does not apply;
I'm confident you are right on that one. Default initialization is not
explicit initialization, so there aren't multiple explicit
initializations.
> I think also the other parts do
> not apply, which would make the code valid.
I think you are also right there, but ithe standard's wording is
ambiguous. I recall fixing lots of cases of wording like that, but it
looks to me like this one slipped by. The standard should almost never
talk about something appearing *IN* some syntactic construct. When it
did say that, the writers usually were thinking of it appearing in some
particular role in the construct, but those thoughts were not
incorporated in the words. Almost invariably, the restriction should
instead talk about the variable appearing *AS* some particular part of
the construct. I thought most of those had been fixed. Looks like this
one hasn't.
> module oad_active
> implicit none
> type active
> integer :: v
> integer :: d = 42
> end type
> end module
>
> module tots_c
> use oad_active
> implicit none
> type(active), save :: trlkold
> data trlkold%v /100/
> end module
>
> program foo
> use tots_c
> implicit none
> if (trlkold%d /= 42) stop 'ERROR d /= 42'
> if (trlkold%v /= 100) stop 'ERROR v /= 100'
> end program foo
In this example, it is the variable trkold that is "of a derived type
for which default initialization is specified." That part is clear (to
me). I'm less sure of exactly what "object has default initialization",
the two possibilities being trkold and trkold%d.
Neither trkold%d nor trkold appear *AS* a data-stmt-object or a
data-i-do-object. That's usually the kind of thing that restrictions
like that really mean. Unfortunately for standards writers who might
have meant something like that, trkold does appear *IN* a
data-stmt-object-list. It appears *IN* the list as a part of trkold%v.
So if I take the literal words of the standard, the code looks illegal
in that it violates the restrictions against tkold appearing *IN* a
data-stmt-object-list. I think there is a fair chance that is not what
was intended, but that's what I think the words say.
I think you have a legit interpretation question for the committee. As I
noted, other simillar ambiguities have been fixed before, and it looks
to me like they just missed this one. Maybe. But maybe it is just
another way in which DATA statements are "special". I can see messy bits
in this one and my vague recollections of debates about problems
relating to partial initialization are bothering me. They make me lack
confidence that the answer to the interpretation question would
necessarily be as simple as in some other cases of similarly vague use
of "in".
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
robin
| Tobias Burnus <bur...@net-b.de> wrote:
| > module oad_active
| > implicit none
| > type active
| > integer :: v
| > integer :: d = 42
| > end type
| > end module
| >
| > module tots_c
| > use oad_active
| > implicit none
| > type(active), save :: trlkold
| > data trlkold%v /100/
| > end module
| >
| > program foo
| > use tots_c
| > implicit none
| > if (trlkold%d /= 42) stop 'ERROR d /= 42'
| > if (trlkold%v /= 100) stop 'ERROR v /= 100'
| > end program foo
|
| In this example, it is the variable trkold that is "of a derived type
| for which default initialization is specified." That part is clear (to
| me). I'm less sure of exactly what "object has default initialization",
| the two possibilities being trkold and trkold%d.
It is only trkold%d that appears in a default initialization.
| Neither trkold%d nor trkold appear *AS* a data-stmt-object or a
| data-i-do-object. That's usually the kind of thing that restrictions
| like that really mean. Unfortunately for standards writers who might
| have meant something like that, trkold does appear *IN* a
| data-stmt-object-list. It appears *IN* the list as a part of trkold%v.
It is only trkold%v that appears in the DATA statement.
| So if I take the literal words of the standard, the code looks illegal
| in that it violates the restrictions against tkold appearing *IN* a
| data-stmt-object-list. I think there is a fair chance that is not what
| was intended, but that's what I think the words say.
Neither variable is being initialized twice.
It still appears to me that the code is legal.
Dick Hendrickson
part of TRKOLD. Do you say your house is on fire if it's only the
kitchen that's burning? It depends. Ditto with is trkold initialized.
Would your answer change if there was only one component? Then is
trkold initialized?
>
> | Neither trkold%d nor trkold appear *AS* a data-stmt-object or a
> | data-i-do-object. That's usually the kind of thing that restrictions
> | like that really mean. Unfortunately for standards writers who might
> | have meant something like that, trkold does appear *IN* a
> | data-stmt-object-list. It appears *IN* the list as a part of trkold%v.
>
> It is only trkold%v that appears in the DATA statement.
>
> | So if I take the literal words of the standard, the code looks illegal
> | in that it violates the restrictions against tkold appearing *IN* a
> | data-stmt-object-list. I think there is a fair chance that is not what
> | was intended, but that's what I think the words say.
>
> Neither variable is being initialized twice.
> It still appears to me that the code is legal.
I'd guess that it's supposed to be non-standard and the wording is murky
or incomplete or wrong. The reason is that DATA is (historically) a
static load-time initialization of storage. The standard doesn't say it
in those words; but everybody knows that's what it means. Default
initialization was designed to work with dynamic variables (allocatable
and automatic variables, intent(out) dummy arguments, etc.)--things that
can't generally be statically initialized. There's no need to invent
default initialization for static derived type variables; the data
statement can be made to work, it's merely sometimes inconvenient. The
standard generally doesn't try to force inter-mixtures of brand new
syntax-like things with old things when there is no compelling reason
for the mixture.
That's just a guess and Richard is right (IMO) about this being a good
thing for an interpretation.
Dick Hendrickson
robin
The house on fire is irrelevant.
What's relevant is:
~~"5.2.3 Initialization":
~~"Explicit initialization alternatively may be specified in a DATA statement
~~unless the variable is of a derived type for which default
~~initialization is specified."
which you elided.
Note in particular that the singular form of "variable" is used.
| > | Neither trkold%d nor trkold appear *AS* a data-stmt-object or a
| > | data-i-do-object. That's usually the kind of thing that restrictions
| > | like that really mean. Unfortunately for standards writers who might
| > | have meant something like that, trkold does appear *IN* a
| > | data-stmt-object-list. It appears *IN* the list as a part of trkold%v.
| >
| > It is only trkold%v that appears in the DATA statement.
| >
| > | So if I take the literal words of the standard, the code looks illegal
| > | in that it violates the restrictions against tkold appearing *IN* a
| > | data-stmt-object-list. I think there is a fair chance that is not what
| > | was intended, but that's what I think the words say.
| >
| > Neither variable is being initialized twice.
| > It still appears to me that the code is legal.
|
| I'd guess that it's supposed to be non-standard and the wording is murky
| or incomplete or wrong.
Well, it could be that the wording is murky or wrong,
but I can think of implementations where one component
is initialized statically and another component is initialized dynamically.
They don't seem to me to be mutually exclusive.
| The reason is that DATA is (historically) a
| static load-time initialization of storage. The standard doesn't say it
| in those words; but everybody knows that's what it means. Default
| initialization was designed to work with dynamic variables (allocatable
| and automatic variables, intent(out) dummy arguments, etc.)--things that
| can't generally be statically initialized. There's no need to invent
| default initialization for static derived type variables; the data
| statement can be made to work, it's merely sometimes inconvenient. The
| standard generally doesn't try to force inter-mixtures of brand new
| syntax-like things with old things when there is no compelling reason
| for the mixture.
A counter example is DOUBLE PRECISION, where double colons may be included,
or may be omitted.
Another counter example is ADVANCE= "NO".
Yet another is the function REAL with a kind value.
There are probably quite a few others.
Tobias Burnus
> So if I take the literal words of the standard, the code looks illegal
> in that it violates the restrictions against tkold appearing *IN* a
> data-stmt-object-list. I think there is a fair chance that is not what
> was intended, but that's what I think the words say.
>
> I think you have a legit interpretation question for the committee.
Thanks for looking at the standard - and for the suggestion to fill an
interpretation request. I did so (J3/11-201) in time for the end of
June meeting (m195). Let's see what the outcome will be.
Tobias
Tobias Burnus
> So if I take the literal words of the standard, the code looks illegal
> in that it violates the restrictions against tkold appearing *IN* a
> data-stmt-object-list. I think there is a fair chance that is not what
> was intended, but that's what I think the words say.
>
> I think you have a legit interpretation question for the committee.
http://j3-fortran.org/doc/meeting/195/11-201r1.txt contains the J3
answer: Component-wise mixing of default and DATA initialization is invalid.
Tobias
Dick Hendrickson
consideration in progress." It's likely to be accepted, but you
shouldn't carve anything important in concrete yet.
Dick Hendrickson