- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi all,
Here is the scenario:
Is there anything in the F90 standard that says that I shouldn't be able to pass INT(x) as an argument to sub because it is an I*4 expression being passed to a dummy arg which is an I*4 array?
I am running a fortran lint program that is complaining about just such a situation, but I see nothing in the standard that says this is not allowable since the return value of INT(x) should, in fact, be an I*4 array.
Thanks in advance,
Chris
Here is the scenario:
PROGRAM test REAL :: x(10) CALL sub(INT(x)) END PROGRAM SUBROUTINE sub(y) INTEGER :: x(:) END SUBROUTINE
Is there anything in the F90 standard that says that I shouldn't be able to pass INT(x) as an argument to sub because it is an I*4 expression being passed to a dummy arg which is an I*4 array?
I am running a fortran lint program that is complaining about just such a situation, but I see nothing in the standard that says this is not allowable since the return value of INT(x) should, in fact, be an I*4 array.
Thanks in advance,
Chris
Link Copied
4 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Did you perhaps mean y(:) in the subroutine? As written, y is real and conflicts with the integer type of INT(x).
Now if you did mean y(:), then you have another problem - y is a deferred-shape array for which you cannot pass a scalar. Also, a deferred-shape array requires an explcit interface to be visible to the caller.
Now, let's see what happens if you had declared Y as Y(*) instead (assumed-size). The standard prohibits this, saying, "If the actual argument is scalar, the corresponding dummy argument shall be scalar unless the actual argument is an element of an array that is not an assumed-shape or pointer array, or a substring of such an element."
So, this code is non-standard no matter how you slice it.
Steve
Now if you did mean y(:), then you have another problem - y is a deferred-shape array for which you cannot pass a scalar. Also, a deferred-shape array requires an explcit interface to be visible to the caller.
Now, let's see what happens if you had declared Y as Y(*) instead (assumed-size). The standard prohibits this, saying, "If the actual argument is scalar, the corresponding dummy argument shall be scalar unless the actual argument is an element of an array that is not an assumed-shape or pointer array, or a substring of such an element."
So, this code is non-standard no matter how you slice it.
Steve
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Steve,
Yes, I did mean y(*) in the subroutine. Sorry for the confusion.
I guess my point is that since x is declared as an array in the program scope, and INT now being a generic interface in F90, then shouldn't INT(x) actually return an array of integers? If so, then shouldn't the call to sub be passing an array of integers to the subroutine?
And if that is the case, then I see no reason why the compiler should treat it any differently than if I were to pass any other fixed dimension integer array.
As it stands right now, CVF will successfully compile this situation, as amended above, with F90 standards checking turned on. It's only flint that seems to complain.
Thanks,
Chris
Yes, I did mean y(*) in the subroutine. Sorry for the confusion.
I guess my point is that since x is declared as an array in the program scope, and INT now being a generic interface in F90, then shouldn't INT(x) actually return an array of integers? If so, then shouldn't the call to sub be passing an array of integers to the subroutine?
And if that is the case, then I see no reason why the compiler should treat it any differently than if I were to pass any other fixed dimension integer array.
As it stands right now, CVF will successfully compile this situation, as amended above, with F90 standards checking turned on. It's only flint that seems to complain.
Thanks,
Chris
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Darn - missed that X was an array and therefore INT(X) is an array. With Y(*) as the argument declaration, this looks ok to me.
Steve
Steve
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Your code is allowed, but what matters is what you do with x in sub. Try adding INTENT(IN) to declaration of x in sub. If CVF accepts the code, flint is wrong. However, if it doesn't, that means that you tried to change value of x in the subroutine, but actual argument is not a variable, but an expression. I'm not sure if this is allowed by the standard (but it's not required for compiler to recognize it without an explicit interface -- that's why tools like flint exist after all).
In the actual case, though, I believe (though I'm not positive) that even that should do no harm, since temporary INT(x) is created on the stack and removed after CALL so whatever changes on formal argument subroutine had done would just go down the drain without overwriting anything relevant.
Jugoslav
In the actual case, though, I believe (though I'm not positive) that even that should do no harm, since temporary INT(x) is created on the stack and removed after CALL so whatever changes on formal argument subroutine had done would just go down the drain without overwriting anything relevant.
Jugoslav

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