- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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]
Link Copied
4 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 !
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 !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well, I'm also a member! But that doesn't make me infallible!
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page