Symbols in function return specifiers

Hi,

I'm wondering whether the following is legal and if so, what the exact
meaning is:

CHARACTER(len=x) FUNCTION test (x)
IMPLICIT REAL(x)
INTEGER :: x
END FUNCTION test

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.

But should it be interpreted as if it were the first data declaration
after IMPLICIT? Which would mean it were REAL in this case, right?

In 5.1.1.1 of the draft F2003 standard (derived type as function result)
it states, though:

"Where a data entity is declared explicitely using the TYPE type
specifier, the specified derived type shall have been previously in the
scoping unit or be accessible there by use or host association. If the
data entity is a function result, the derived type may be specified in
the FUNCTION statement provided the derived type is defined within the
body of the function or is accessible there by use or host association.
If the derived type is specified in the FUNCTION statement and is
defined within the body of the function, it is as if the function result
variable was declared with that derived type immediatelly following the
derived-type-def of the specified derived type."

According to a similar logic, the example above should be equivalent to:

FUNCTION test (x)
IMPLCIIT REAL(x)
INTEGER :: x
CHARACTER(len=x) :: test
END FUNCTION test

and because of this legal... How's that really? Unfortunatelly, I
couldn't find anything regarding this exact situation in the standard.

Is there any difference whether the function is inside a MODULE with an
IMPLICIT context itself or on the top-level without one?

Thanks,
Daniel

--
Done: Arc-Bar-Sam-Val-Wiz, Dwa-Elf-Gno-Hum-Orc, Law-Neu-Cha, Fem-Mal
Underway: Cav-Dwa-Law-Fem
To go: Cav-Hea-Kni-Mon-Pri-Ran-Rog-Tou

On 18 août, 17:03, Daniel Kraft <d...@domob.eu> wrote:
> Hi,
>
> I'm wondering whether the following is legal and if so, what the exact
> meaning is:
>
> CHARACTER(len=x) FUNCTION test (x)
> IMPLICIT REAL(x)
> INTEGER :: x
> END FUNCTION test

It seems OK

>
> 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.

The IMPLICIT statement has no influence here because overridden by the
declaration INTEGER :: x

>
> But should it be interpreted as if it were the first data declaration
> after IMPLICIT? Which would mean it were REAL in this case, right?
>
> In 5.1.1.1 of the draft F2003 standard (derived type as function result)
> it states, though:
>
> "Where a data entity is declared explicitely using the TYPE type
> specifier, the specified derived type shall have been previously in the
> scoping unit or be accessible there by use or host association. If the
> data entity is a function result, the derived type may be specified in
> the FUNCTION statement provided the derived type is defined within the
> body of the function or is accessible there by use or host association.
> If the derived type is specified in the FUNCTION statement and is
> defined within the body of the function, it is as if the function result
> variable was declared with that derived type immediatelly following the
> derived-type-def of the specified derived type."
>
> According to a similar logic, the example above should be equivalent to:
>
> FUNCTION test (x)
> IMPLCIIT REAL(x)
> INTEGER :: x
> CHARACTER(len=x) :: test
> END FUNCTION test

This is equivalent to the first solution

>
> and because of this legal... How's that really? Unfortunatelly, I
> couldn't find anything regarding this exact situation in the standard.
>
> Is there any difference whether the function is inside a MODULE with an
> IMPLICIT context itself or on the top-level without one?

If the function is outside a module and declared as EXTERNAL in the
main program,
then you may have a trouble the length returned string :

PROGRAM t

CHARACTER(10),EXTERNAL :: test

write(*,*) test(4)
write(*,*) test(5)
write(*,*) test(6)
END

CHARACTER(len=x) FUNCTION test (x)
INTEGER :: x
test='abcdefgh'
END FUNCTION test

Result :

abcd
abcden��
abcdef

As you see, some strange characters my appear because the function
length (10) is greater than the argument x. Of course, trying test(11)
could lead to a segmentation fault.

It is much better to put the function in a module or in the contain
part of the caller :

PROGRAM t
write(*,*) test(4)
write(*,*) test(5)
write(*,*) test(6)
CONTAINS
FUNCTION test (x)
INTEGER :: x
CHARACTER(len=x) :: test
test='abcdefgh'
END FUNCTION test
END PROGRAM

abcd
abcde
abcdef


>
> Thanks,
> Daniel
>
> --
> Done: Arc-Bar-Sam-Val-Wiz, Dwa-Elf-Gno-Hum-Orc, Law-Neu-Cha, Fem-Mal
> Underway: Cav-Dwa-Law-Fem
> To go: Cav-Hea-Kni-Mon-Pri-Ran-Rog-Tou

Daniel Kraft <d@domob.eu> wrote:

> I'm wondering whether the following is legal and if so, what the exact
> meaning is:
>
> CHARACTER(len=x) FUNCTION test (x)
> IMPLICIT REAL(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 5.1.1.1 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
that para.

> 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
type paraeters."

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
wording aside....

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
illegal.

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
missed.

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

On 18 août, 19:01, nos...@see.signature (Richard Maine) wrote:
> Daniel Kraft <d...@domob.eu> wrote:
> > I'm wondering whether the following is legal and if so, what the exact
> > meaning is:
>
> > CHARACTER(len=x) FUNCTION test (x)
> > IMPLICIT REAL(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 itis.
>
> 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 5.1.1.1 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
> that para.
>
> > 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
> type paraeters."
>
> 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
> wording aside....
>
> 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
> illegal.
>
> 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
> missed.
>
> --
> 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
gfortran) :

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

fj wrote:
> On 18 août, 19:01, nos...@see.signature (Richard Maine) wrote:
>> Daniel Kraft <d...@domob.eu> wrote:
>>> I'm wondering whether the following is legal and if so, what the exact
>>> meaning is:
>>> CHARACTER(len=x) FUNCTION test (x)
>>> IMPLICIT REAL(x)
>>> INTEGER :: x
>>> END FUNCTION test
>> I don't think so - ...
....
>> 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.
>>
....
>> 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
>> type para[m]eters."
....
>> 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
>> illegal.
>>
>> 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.
>>
....
>> 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
>> missed.

I didn't check, Richard, but did see a missing "m" in "para[m]eter"...

....

> Strange : I tested the example with 3 compilers (g95, ifort and
> gfortran) :
>
> 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


I thought Richard's answer would be the answer when I saw it but
compiled the code w/ CVF to see what it would do -- it didn't like it
specifically on the same point as Richard notes--trying to redefine the
X as integer when it's implicitly typed.

C:\Temp> df /c testlang.f90
Compaq Visual Fortran Optimizing Compiler Version 6.6 (Update C)

testlang.f90
testlang.f90(3) : Error: This name has already been assigned a data
type. [X]
INTEGER :: x
-------------^

fj wrote:
> On 18 août, 19:01, nos...@see.signature (Richard Maine) wrote:
>> Daniel Kraft <d...@domob.eu> wrote:
>>> I'm wondering whether the following is legal and if so, what the exact
>>> meaning is:
>>> CHARACTER(len=x) FUNCTION test (x)
>>> IMPLICIT REAL(x)
>>> INTEGER :: x
>>> END FUNCTION test
>
> Strange : I tested the example with 3 compilers (g95, ifort and
> gfortran) :
>
> 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

I'm working on gfortran, so this is the reason why gfortran does not yet
complain... It will in the future, however, if I get this fixed
correctly

Daniel

--
Done: Arc-Bar-Sam-Val-Wiz, Dwa-Elf-Gno-Hum-Orc, Law-Neu-Cha, Fem-Mal
Underway: Cav-Dwa-Law-Fem
To go: Cav-Hea-Kni-Mon-Pri-Ran-Rog-Tou

On Aug 18, 10:37 am, fj <francois.j...@irsn.fr> wrote:
> On 18 août, 19:01, nos...@see.signature (Richard Maine) wrote:
>
>
>
> > Daniel Kraft <d...@domob.eu> wrote:
> > > I'm wondering whether the following is legal and if so, what the exact
> > > meaning is:
>
> > > CHARACTER(len=x) FUNCTION test (x)
> > > IMPLICIT REAL(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 5.1.1.1 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
> > that para.
>
> > > 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
> > type paraeters."
>
> > 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
> > wording aside....
>
> > 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
> > illegal.
>
> > 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
> > missed.
>
> > --
> > 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
> gfortran) :
>
> 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

Just because a compiler does not give a warning for a
construct does not make it standard conforming. The
Fortran standard does not require a standard-conforming
Fortran processor to diagnose this particular error.
There are errors that a standard-conforming processor
must be capable of diagnosing, but this error is not
among them.

Bob Corbett

"Richard Maine" <nospam@see.signature> wrote in message
news:1ilv35l.1b9j4r319q7q0uN%nospam@see.signature. ..

> Daniel Kraft <d@domob.eu> wrote:

>> In 5.1.1.1 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
> that para.

>> 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.

But similar logic is all we've got in many situations. When the
result variable is given its type in the FUNCTION statement, where
else in the standard does it say where that effective specification
should be ordered within the specification part of the function?
Example:

C:\gcc_mingw64\clf\imp_fun>type imp_fun.f90
function imp_fun1(x)
implicit character(7) (i)
implicit character(len(imp_fun1)) (y)
integer x

imp_fun = ''
end function imp_fun1

function imp_fun2(x)
implicit character(len(imp_fun2)) (y)
implicit character(7) (i)
integer x

imp_fun = ''
end function imp_fun2

function imp_fun3(x)
implicit character(len(imp_fun3)) (y)
implicit character(len(yzx)) (i)
integer x

imp_fun = ''
end function imp_fun3

C:\gcc_mingw64\clf\imp_fun>gfortran -c imp_fun.f90
imp_fun.f90:10.35:

implicit character(len(imp_fun2)) (y)
1
Error: Conflict in attributes of function argument at (1)
imp_fun.f90:18.35:

implicit character(len(imp_fun3)) (y)
1
Error: Conflict in attributes of function argument at (1)
imp_fun.f90:19.26:

implicit character(len(yzx)) (i)
1
Error: 'string' argument of 'len' intrinsic at (1) must be CHARACTER

Obviously function imp_fun1 is OK, but shouldn't imp_fun2 also pass
because N1723.pdf, section 12.6.2.2 says that the type and type
parameters of the result variable are determined by the implicit
typing rules in force within the function subprogram. Since variables
starting with the letter 'i' are implicitly typed as CHARACTER(7)
within function imp_fun2 it should be OK to use the LEN of the result
variable in the specification part because it follows the declaration
of imp_fun2 given implicitly in the FUNCTION statement unless it is
reshuffled syntactically somehow as given in the passage under
dispute.

Function imp_fun3 obviously is in error and this brings us back to
the reshuffling as generalized from 5.1.1.1 of f03 because that
passage alone seems to be able to permit the standard to forbid this
kind of recursive type parameter definition.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Richard Maine wrote:
> Daniel Kraft <d@domob.eu> wrote:
>
>> I'm wondering whether the following is legal and if so, what the exact
>> meaning is:
>>
>> CHARACTER(len=x) FUNCTION test (x)
>> IMPLICIT REAL(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.

Yes, I am. However, I admit that as a code-writer, I prefer

INTEGER FUNCTION xxx ()

to

FUNCTION xxx ()
...
INTEGER :: xxx

But only so for intrinsic-types without type-parameters and not in the
case mentioned above, of course.

> 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
> type paraeters."
>
> 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
> illegal.

Thanks Richard, this is what I was looking for!

Cheers,
Daniel

--
Done: Arc-Bar-Sam-Val-Wiz, Dwa-Elf-Gno-Hum-Orc, Law-Neu-Cha, Fem-Mal
Underway: Cav-Dwa-Law-Fem
To go: Cav-Hea-Kni-Mon-Pri-Ran-Rog-Tou

Daniel Kraft wrote:
> fj wrote:
>> On 18 août, 19:01, nos...@see.signature (Richard Maine) wrote:
>>> Daniel Kraft <d...@domob.eu> wrote:
>>>> I'm wondering whether the following is legal and if so, what the exact
>>>> meaning is:
>>>> CHARACTER(len=x) FUNCTION test (x)
>>>> IMPLICIT REAL(x)
>>>> INTEGER :: x
>>>> END FUNCTION test
>>
>> Strange : I tested the example with 3 compilers (g95, ifort and
>> gfortran) :
>>
>> 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
>
> I'm working on gfortran, so this is the reason why gfortran does not yet
> complain... It will in the future, however, if I get this fixed
> correctly

Daniel,

while you are at it, PR30239 seems to be related (or a special case of
yours).

Regards

Daniel