Re: Symbols in function return specifiers
- From: fj <francois.jacq@xxxxxxx>
- Date: Mon, 18 Aug 2008 10:37:52 -0700 (PDT)
On 18 août, 19:01, nos...@xxxxxxxxxxxxx (Richard Maine) wrote:
Daniel Kraft <d...@xxxxxxxx> wrote:
I'm wondering whether the following is legal and if so, what the exact
CHARACTER(len=x) FUNCTION test (x)
INTEGER :: x
END FUNCTION test
I don't think so - see below. I hate that style of function declaration,
partly because of issues like this. It takes special-case wording in the
standard to make them work. I realize that you are writing a compiler
instead of code (anyway, something gave me that impression). For code
witers, the answer is much simpler; just don't do things like that
anyway, even if it is allowed. Compiler writers have to put up with such
junk if the standard says so.
The problem is, is the "x" in the return type specification given as
prefix interpreted in the IMPLICIT context of the function? I guess it is.
No way. That one is "easy". X is integer. Period. It is explicitly
declared so. The only other possibility is that the code is illegal
because of ordering problems. You can *NEVER* have one variable have two
different types at different points in the same scoping unit. Nor can
you ever have a variable's explicitly-declared type be just ignored.
The only two posibilities even worth looking into are that X is integer
or the code is illegal. If you are considering anything else, you are on
the wrong track already.
In 18.104.22.168 of the draft F2003 standard (derived type as function result)
None of that is relevant at all. This is not a derived-type function
result. And no, you can't extrapolate as though this were simillar in
some way. Function results have special-case rules, such as the one in
According to a similar logic,...
No. You can't generalize special-case rules as though they were general
principles, since they are rather the opposite of general principles.
"Similar logic" isn't good enough.
It is sort of hard to find, I realize, but the relevant rule in f2003 is
in 7.1.6, in the first para after Note 7.9. realize first that the x in
len=x is a specification expression (per R1228, the prefix-spec in the
function statement is a declaration-type-spec; per C501, an expression
in a declaration-type-spec shall be a specification expression). Then
"A variable in a specification expression shall have its type and type
parameters, if any, specified by a previous declaration in the same
scoping unit, by the implicit typing rules in effect for the scoping
unit, or by host or use association. If a variable in a specification
expression is typed by the implicit typing rules, its appearance in any
subsequent type declaration statement shall confirm the implied type and
I have long found the logic of the wording in that para to be roundabout
and messy. I recall that there were multiple interp questions about it
at several times. For example, I'd normally say that a variable wasn't
typed by the implicit typing rules if there was an explicit declaration.
This para takes the roundabout approach of treating the variable as
though it were initially typed by the implicit typing rules, but then
later verified by the explicit declaration; I don't think that's the
descriptive mode used anywhere else, but anyway, my bitches about the
In your case, following the above roundabout logic, your variable x is
first typed as real by the implicit typing rules because the declaration
of x is not prior to its use. But then you have a subsequent type
declaration of x that does not confirm its type. Thus, the code is
There might possibly be a special-case rule somewhere for function
statements. I don't off-hand see one, but I could have missed it. If
there is one, it has to actually be for this exact scenario, though. A
special case rule for something that you think of as simillar will *NOT*
suffice. In particular, the para that you quoted does not apply.
Is there any difference whether the function is inside a MODULE with an
IMPLICIT context itself or on the top-level without one?
No. The wording about "the implicit typing rules in effect for the
scoping unit" are a (roundabout) way of saying that you don't just look
at the implicit statements so far, but instead at what the implicit
typing rules for the scoping unit are, even if that turns out to be
determined by subsequent statements (which can't happen in many ways,
but this is one). I'd have preferred that this all be spelled out more
clearly (and I'd have even more preferred that the rules be simpler and
have no special cases), but it isn't.
P.S. Pardon my typos. Must be the hour. This posting seemed to have more
than my usually large number of them. I already corrected... um... I
lost count, but a lot. That probably means there are yet more that I
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Strange : I tested the example with 3 compilers (g95, ifort and
g95 and gfortran compile the two cases without any warning, even with -
Wall. ifort compiles only when the type of the function is declared
after the declaration INTEGER :: x
- Prev by Date: Re: Use in Modules
- Next by Date: Re: Symbols in function return specifiers
- Previous by thread: Re: Symbols in function return specifiers
- Next by thread: Re: Symbols in function return specifiers