Home > Archive > Fortran > October 2006 > Pointer Arguments
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| In F90/95 you are allowed to pass a pointer actual argumnet to a procedure
with a non-pointer dummy argument provided the pointer is associated. Is
there any way for the procedure to do a runtime precondition check on the
argument to find out if the actual argument is not a pointer or, if it is,
that it has a target?
Failing a source code checking solution, I can't find any runtime error
trapping option in IVF9.1 that would do this; maybe other compilers have
this option. Can anyone advise on this?
Paul Holden
| |
| Jugoslav Dujic 2006-10-30, 7:15 pm |
| PJH wrote:
| In F90/95 you are allowed to pass a pointer actual argumnet to a procedure
| with a non-pointer dummy argument provided the pointer is associated. Is
| there any way for the procedure to do a runtime precondition check on the
| argument to find out if the actual argument is not a pointer or, if it is,
| that it has a target?
|
| Failing a source code checking solution, I can't find any runtime error
| trapping option in IVF9.1 that would do this; maybe other compilers have
| this option. Can anyone advise on this?
If the pointer is NULLified, you'll get an access violation on access. I
suppose you can test for that in advance using:
SUBROUTINE Foo(Bar)
REAL, TARGET, INTENT(IN):: Bar
REAL, POINTER:: pBar
pBar => Bar
IF (.NOT.ASSOCIATED(pBar)) THEN
!Error
I'm don't think it's strictly standard-conforming (AFAICT you're prohibited
from even trying to pass nullified actual argument), but it's reasonably
reliable.
If the pointer is undefined (uninitialized or dangling), all bets are off.
You can't tell in any way whether the memory pointed to is "valid".
--
Jugoslav
___________
www.xeffort.com
Please reply to the newsgroup.
You can find my real e-mail on my home page above.
| |
|
| Thanks Jugoslav
This should be OK for what I need. I'm just trying to put in a bit of
assertion-checking code that will catch any pointer programming errors in
future modifications, so standards compliance is not really an issue. If the
programmer is that bad that the pointer has not even been nullified they
deserve the problems!
Paul Holden
"Jugoslav Dujic" <jdujic@yahoo.com> wrote in message
news:4qblphFma3m2U1@individual.net...
> PJH wrote:
> | In F90/95 you are allowed to pass a pointer actual argumnet to a
procedure
> | with a non-pointer dummy argument provided the pointer is associated. Is
> | there any way for the procedure to do a runtime precondition check on
the
> | argument to find out if the actual argument is not a pointer or, if it
is,
> | that it has a target?
> |
> | Failing a source code checking solution, I can't find any runtime error
> | trapping option in IVF9.1 that would do this; maybe other compilers have
> | this option. Can anyone advise on this?
>
> If the pointer is NULLified, you'll get an access violation on access. I
> suppose you can test for that in advance using:
>
> SUBROUTINE Foo(Bar)
>
> REAL, TARGET, INTENT(IN):: Bar
> REAL, POINTER:: pBar
>
> pBar => Bar
> IF (.NOT.ASSOCIATED(pBar)) THEN
> !Error
>
> I'm don't think it's strictly standard-conforming (AFAICT you're
prohibited
> from even trying to pass nullified actual argument), but it's reasonably
> reliable.
>
> If the pointer is undefined (uninitialized or dangling), all bets are off.
> You can't tell in any way whether the memory pointed to is "valid".
>
> --
> Jugoslav
> ___________
> www.xeffort.com
>
> Please reply to the newsgroup.
> You can find my real e-mail on my home page above.
| |
| Richard E Maine 2006-10-30, 7:15 pm |
| Jugoslav Dujic <jdujic@yahoo.com> wrote:
> SUBROUTINE Foo(Bar)
>
> REAL, TARGET, INTENT(IN):: Bar
> REAL, POINTER:: pBar
>
> pBar => Bar
> IF (.NOT.ASSOCIATED(pBar)) THEN
> !Error
>
> I'm don't think it's strictly standard-conforming (AFAICT you're prohibited
> from even trying to pass nullified actual argument), but it's reasonably
> reliable.
That is certainly nonstandard. I wouldn't count on it working.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Richard E Maine 2006-10-30, 7:15 pm |
| Richard E Maine <nospam@see.signature> wrote:
> Jugoslav Dujic <jdujic@yahoo.com> wrote:
>
>
> That is certainly nonstandard. I wouldn't count on it working.
I was a bit in a hurry when I posted that, needing to run off to an
appointment. Back now. I see that I elided a bit too much. While the
code in question is nonstandard and I wouldn't count on it working, the
reason is in the parts I elided (namely the passing of a nullified
actual argument, as Jugoslav mentioned), rather than in what I showed.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Steve Lionel 2006-10-30, 7:15 pm |
| PJH wrote:
> In F90/95 you are allowed to pass a pointer actual argumnet to a procedure
> with a non-pointer dummy argument provided the pointer is associated. Is
> there any way for the procedure to do a runtime precondition check on the
> argument to find out if the actual argument is not a pointer or, if it is,
> that it has a target?
Since you are using Intel Fortran, you could do this:
if (loc(argument) == 0) then
print *, "Argument not associated"
This won't tell you whether or not it is a pointer, but it will tell
you that the address pointer is null.
In recent updates to the Intel compiler there is a new /check:pointer
option (-check pointer on Linux and Mac) which will do a run-time check
to see if you are referencing a null pointer. This would theoretically
catch the problem at the call site. We've seen some cases where the
error is improperly reported but fix those as we find them.
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/
My Fortran blog
http://www.intel.com/software/drfortran
|
|
|
|
|