Re: Does F90 do type checking when calling module subroutines?
- From: Richard E Maine <nospam@xxxxxxxxxxxxx>
- Date: Mon, 25 Apr 2005 14:10:29 -0700
In article <pan.2005.04.25.20.03.30.322672@xxxxxxxxxxxxxxxxxxxxxx>,
Neilen Marais <junkmail@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> I was under the impression that if you call subroutines from modules, f90
> would check the call paramter types?
The standard doesn't quite require that, but it sure encourages it, and
I haven't yet seen a compiler that doesn't do it.
> I'm using Intel fortran under linux.
> I have a subroutine defined in a module like this:
>
> MODULE parseinput
> INTERFACE read_namelists
> MODULE PROCEDURE read_namelists
> END INTERFACE
> CONTAINS
>
> SUBROUTINE read_namelists(infile)
> IMPLICIT NONE
> INTEGER(I4B), INTENT(in) :: infile
>
>
> In another .f90 file, I included this subroutine with a USE parseinput
> statement. Then I erroneously proceed to call it with a character array
> (i.e. string) as parameter instead of an integer. Yet I get no compiler
> error or warning! Is this the expected behaviour? If it is, is there
> any way I can convince the compiler to let me know of my evil ways?
I would certainly gripe at a vendor that failed to diagnose such
problems, but first I'd wonder about one possibility for user confusion
here. In particular...
Is there some reason why you have the interface block? What that
interface block does is make a generic with this as one specific. It is
certainly possible that somewhere else there is another interface block
that also has a specific with a character dummy. I can't tell from
looking at this alone, but that is certainly the kind of reason why one
makes generics. If that's the case, then there is no error here except
for user confusion.
I might add that I find one thing slightly unusual about this generic -
namely that the generic and the specific (at least this specific) have
the same name. That might have contributed to the confusion. I had to
check the standard to see whether that was allowed for user-defined
generics. Apparently it is allowed... but I still wouldn't do it. I also
wonder whether that might be something unusual enough to have thrown off
the compiler.
I don't have a recent version of the Intel compiler handily installed to
check myself, but I might recommend making a severely cut down test case
(that is unless the above explanation leads you to the problem).
Shouldn't take much more than just the lines of code you showed, with a
procedure with no body (or maybe a body that just prints "here I am"),
plus a trivial main program to call it. That would be small enough to be
sure that there were no external factors (such as other interface
blocks) and would also allow experimentation with changing the name of
the specific to be different from that of the generic.
Or if you don't have reason to be using generics, you might just get rid
of the interface block - though I'd still be curious whether the
compiler is getting something wrong in it.
--
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
.
- Follow-Ups:
- Re: Does F90 do type checking when calling module subroutines?
- From: Neilen Marais
- Re: Does F90 do type checking when calling module subroutines?
- References:
- Does F90 do type checking when calling module subroutines?
- From: Neilen Marais
- Does F90 do type checking when calling module subroutines?
- Prev by Date: Re: mixing logical with real in equation
- Next by Date: Re: Does F90 do type checking when calling module subroutines?
- Previous by thread: Does F90 do type checking when calling module subroutines?
- Next by thread: Re: Does F90 do type checking when calling module subroutines?
- Index(es):
Relevant Pages
|
|
