Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28469 Discussions

CHARACTER(LEN = LEN(char_arg)) as a FUNCTION prefix

yamajun2
Beginner
259 Views
In section 7.13 of the book "Fortran95/2003 Explained" by Metcalf, Reid & Cohen, there is an example of a function which returns CHARACTER of the length of dummy-argument. It causes syntax error in IVF v11.1.

In the following code, FUNCTION line2 (using prefix) causes error while FUNCTION line1 (using RESULT) works fine.
It seems that there is something wrong with the FUNCTION prefix.




[cpp]MODULE m_test
IMPLICIT NONE
CONTAINS
!-------------------------------
FUNCTION line1(char_arg) RESULT(res)
CHARACTER(LEN = *), INTENT(IN) :: char_arg
CHARACTER(LEN(char_arg)) :: res
res = REPEAT('@', LEN(char_arg))
RETURN
END FUNCTION line1
!-------------------------------
CHARACTER(LEN = LEN(char_arg)) FUNCTION line2(char_arg) ! 7.13 p151
CHARACTER(LEN = *), INTENT(IN) :: char_arg
line2 = REPEAT('@', LEN(char_arg))
RETURN
END FUNCTION line2
!-------------------------------
END MODULE m_test
!================================
PROGRAM test
USE m_test
IMPLICIT NONE
PRINT *, line1('1234567')

PRINT *, line1('123')

STOP
END PROGRAM test[/cpp]


0 Kudos
4 Replies
TimP
Honored Contributor III
259 Views
http://www.liv.ac.uk/HPC/HTMLF90Course/HTMLF90CourseNotesnode170.html
expresses an opinion contrary to MR&C, agreeing with ifort. However, gfortran accepts your syntax. It would be worth a submission on premier.intel.com to have experts sort this out, if we don't get an answer here over the next day or so.
0 Kudos
Steven_L_Intel1
Employee
259 Views
I would say that this is not legal. The error message you get is perhaps a bit confusing, but I understand how it got there.

The "CHARACTER(LEN=LEN(char_arg))" is a "declaration-type-spec" and the "LEN=LEN(char_arg)" is a "type-param-value". Constraint C501 says:

13 C501 (R502) In a declaration-type-spec, every type-param-value that is not a colon or an asterisk shall
14 be a specification-expr .

The rules for a specification expression require:

9 A variable in a specification expression shall have its type and type parameters, if any, specified by a
10 previous declaration in the same scoping unit, by the implicit typing rules in effect for the scoping unit,
11 or by host or use association. If a variable in a specification expression is typed by the implicit typing
12 rules, its appearance in any subsequent type declaration statement shall confirm the implied type and
13 type parameters.

In your case, char_arg has NOT had its type and type parameters previously specified - indeed, they are specified in the next statement. Therefore the implicit type rules are followed and char_arg, since IMPLICIT NONE is in effect, has no type. Even if there were no IMPLICIT NONE it would be default REAL. This is not permitted as an argument to LEN so you get the error:

The data types of the argument(s) are invalid.

Other errors fall out from that.

I am aware that some compilers, as an extension, "look ahead" for declarations when considering specification expressions. ifort does not.

I would have expected an error about char_arg not having a type, rather than it being "the wrong type". It also puzzles me that if I change the IMPLICIT NONE to IMPLICIT CHARACTER(C) then the source compiles ok - I would have expected an error on the explicit declaration of char_arg because the length is different. I'll discuss this with the team.
0 Kudos
yamajun2
Beginner
259 Views
So there are different opinions on this topic.

I personally had a feeling that the behavior of IVF is more natural than the "fortran95/2003 explained". But because the authors of the book are members of the ISO comittee, I would like to confirm about it.

Thank you very much, tim18 and Steve !


0 Kudos
Steven_L_Intel1
Employee
259 Views
Well, I'm also a member! But that doesn't make me infallible!
0 Kudos
Reply