Re: Fortran function returning incorrect type based on function name

From: Dennis Shea <shea_at_nyahnyahspammersnyahnyah>
Date: Wed Dec 04 2013 - 22:59:12 MST

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.

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
Received on Wed Dec 4 22:59:23 2013

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