Re: Fortran function returning incorrect type based on function name

From: Alan Brammer <abrammer_at_nyahnyahspammersnyahnyah>
Date: Thu Dec 05 2013 - 11:53:54 MST

Thanks, for the educational discussion.  I realised the error of my ways, rather than define the function name as real, which threw an error,  if I define the function itself as real it returns the expected result. This change only matters in the stub file, the f90 file was content either way. 

  e.g.  instead of  “FUNCTION lbcd()”  I should use  “REAL FUNCTION lbcd()"

Thanks all. I can probably have slightly more explicit code now in the future, and keep function names that make sense. 


On December 5, 2013 at 1:32:51 PM, David Brown ( wrote:

On Dec 4, 2013, at 10:59 PM, Dennis Shea <> wrote:

> Actually f90 onward also has "ancient" fortran's implicit typing.
> This was done for backward compatibility.
> Sometimes fortran compilers have an option that will not allow
> implicit typing. However, this is not part of any fortran standard.

It might not be part of the official Fortran 77 standard but I think


is pretty much assured to be available in a Fortran compiler nowadays. According to the Wikipedia article on Fortran it was part of the DOD MIL-STD-1753 extension to Fortran 77 in 1978, and has been
adopted as standard in Fortran 90. I don't know if that could help with the issue that Alan has encountered though.


> Why did fortran do this? Don't know!
> Why are there no 'key words' in fortran? Don't know!
> Why are spaces not significant? Don't know!
> etc
> There was no experience in 'high level' languages in the late 1950s.
> ---
> f90 'looks' like it requires explicit typing because almost all example
> use declarations like
> integer
> real
> and most f90 codes and classes/tutorials use explicit typing
> --
> If u google 'fortran implicit typing', you will find many f77 example
> but few f90 examples.
> D
> On 12/4/13, 9:02 PM, Alan Brammer wrote:
>> Rick,
>> I actually didn’t know/recall that about variables named i though n and that explains it perfectly. Was just working through function names and anything in that range returned as an integer. I found I was unable to define the name of the function as a variable in the wrapper, which I believe is f77 based. So I guess the wrapper is forcing an integer type over the explicit definition in the f90 code.
>> I’ll just come up with creative names to avoid those letters.
>> Thanks,
>> Alan.
>> --
>> Alan Brammer, PhD Candidate,
>> Department of Atmospheric and Environmental Sciences,
>> University at Albany, SUNY,
>> On December 4, 2013 at 10:45:31 PM, ( wrote:
>> Hi Alan,
>> As you likely know, ancient versions of fortran (f77 and prior) had
>> explicit typing in the absense of explicit programmer-specified types:
>> any variable/function beginning with i--through--n was presumed of
>> integer type, all others were considered real. I don't know what the
>> deal is with more modern versions of fortran.
>> I see that you are properly declaring the types of your functions
>> *within* their definition. I'm wondering if you need to declare their
>> types in the outer calling scope? That said, I tried a little
>> experiment to test that notion and got a compiler error rather than a
>> silent type conversion.
>> FWIW...
>> Rick
>> On Wed, 4 Dec 2013 22:22:47 -0500
>> Alan Brammer <> wrote:
>>> Hi all,
>>> I have 2 iterations of the exact same code below. One function
>>> named “abcd" that returns a float as expected, one function named
>>> “lbcd" which incorrectly returns an integer, though not even the
>>> nearest integer but just zero.
>>> I’ve narrowed this down to whether or not the function begins with
>>> the letter l ?
>>> The returned xx value is correct, but the function value returned is
>>> the issue.
>>> I imagine this is an issue with WRAPIT possibly, so below is the
>>> version I have. I’ve never noticed the below syntax error in `WRAPIT
>>> -d` and wrapped routines typically work as expected.
>>> WRAPIT Version: 120209
>>> nbits = 64
>>> FORTRAN COMPILER (f90c): gfortran
>>> FORTRAN COMPILER OPTIONS (fopts): -m64 -fPIC -v -c
>>> -fno-second-underscore
>>> A syntax error occurred while parsing:
>>> gcc -fPIC -m64 -c -I/ct12/abrammer/ncl6.1.2//include WRAPIT.c
>>> LINKER SUFFIX (ld_suffix): WRAPIT.o -o NONE
>>> gcc -m64 -fPIC -shared WRAPIT.o -o NONE -lgfortran
>>> Thanks,
>>> Alan.
>>> p.s. The code here is trivial and getting the result is not the
>>> issue.
>> _______________________________________________
>> ncl-talk mailing list
>> List instructions, subscriber options, unsubscribe:
> _______________________________________________
> ncl-talk mailing list
> List instructions, subscriber options, unsubscribe:

ncl-talk mailing list
List instructions, subscriber options, unsubscribe:
Received on Thu Dec 5 11:56:19 2013

This archive was generated by hypermail 2.1.8 : Fri Dec 13 2013 - 11:39:30 MST