Pete,
digging back some 50 odd years, my recollection is that calling a
FORTRAN procedure (subroutine or function) with the incorrect data types
will generally result in the compiler trying to be helpful. Thus a FLOAT
will be transformed to an equivalent INTEGER, and vice versa. But
*beware*. Type conversion to integer in FORTRAN gives a result which is
truncated (rounded down), rather than rounded to the nearest integer.
That is still so in FORTRAN 90. In the other direction, the conversion
may be assumed to be rounded.
The code as you describe it will *probably*, because the compiler tries
to be helpful, appear to run successfully. Whether or not the result is
that intended is a question for the authors of the code. Mismatched
types, in general, are *not* a good thing.
There is a lot more to this, of course!
HTH, 73,
Robin, G8DQX
On 18/05/2019 03:59, Pete wrote:
I've been trying to get the ft4d program (2.1.0-rc5) to compile with
Cygwin64 on Windows 10 (just because) and ran across this oddity.
The ft4b subroutine in ft4b.f90 calls the getcandidates4 subroutine
like this:
call
getcandidates4(iwave,fa,fb,syncmin,nfqso,maxcand,savg,candidate, &
ncand,sbase)
where iwave is declared to be a short integer array
integer*2 iwave(NMAX)
But the getcandidates4 subroutine is defined like this:
subroutine
getcandidates4(dd,fa,fb,syncmin,nfqso,maxcand,savg,candidate, &
ncand,sbase)
where dd is declared as
real dd(NMAX)
I presume that this is a bug since the types don't match.
Pete VE5VA
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
