Re: Symbols in function return specifiers
  Home FAQ Contact Sign in
comp.lang.fortran only
 
Advanced search
POPULAR GROUPS

more...

 Up
Re: Symbols in function return specifiers         

Group: comp.lang.fortran · Group Profile
Author: dpb
Date: Aug 18, 2008 11:02

fj wrote:
> On 18 août, 19:01, nos...@see.signature (Richard Maine) wrote:
>> Daniel Kraft 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
-------------^
no comments
diggit! del.icio.us! reddit!