Re: Fortran function returning incorrect type based on function name

On Dec 4, 2013, at 10:59 PM, Dennis Shea <shea@ucar.edu> 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

IMPLICIT NONE

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.

 -dave

>
> 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, brownrig@ucar.edu (brownrig@ucar.edu) 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 <abrammer@albany.edu> 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
>>> OPERATING SYSTEM: Linux
>>> 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
>>> SHARED OBJECT NAME (SharedObj): NONE
>>> LINKER SUFFIX (ld_suffix): WRAPIT.o -o NONE
>>>
>>> LINKING
>>> gcc -m64 -fPIC -shared WRAPIT.o -o NONE -lgfortran
>>> END WRAPIT
>>>
>>>
>>> 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:
>> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>>
> _______________________________________________
> ncl-talk mailing list
> List instructions, subscriber options, unsubscribe:
> http://mailman.ucar.edu/mailman/listinfo/ncl-talk

_______________________________________________
ncl-talk mailing list
List instructions, subscriber options, unsubscribe:
http://mailman.ucar.edu/mailman/listinfo/ncl-talk
Received on Thu Dec 5 11:32:56 2013