Simple function fails

[sindizzy]

I have what seems like a simple function

INTEGER FUNCTION Get_Code( )
   INTEGER CodeX

   CodeX = 0 
   WRITE(188,*) 'CodeX=', CodeX

   Get_Code = CodeX

   RETURN

END FUNCTION

In my main I have (and do not have any other code between these two lines):

INTEGER MyCode

MyCode = Get_Code( )
WRITE(188,*) 'MyCode=', MyCode

My debug text file shows:

CodeX= 0
MyCode= -2147483648

I cant figure out what I am doing wrong. This should be something simple but am just not able to determine the source of the issue.

[IanH]

Code fragments result in us playing guessing games.

Is an explicit interface for the function accessible in the scoping unit of the main program?  If not, do you declare the type of the function in the main program?  Do you have IMPLICIT NONE statements in your program units?

[sindizzy]

I'll be honest, I inherited this project from an engineer who left the company and I haven't done Fortran in a couple of years. From what you stated, I looked at the main and it does not have the IMPLICIT NONE. So that suggests I need to declare the function in my main like so: 

INTEGER Get_Code, MyCode

MyCode = Get_Code( )
WRITE(188,*) 'MyCode=', MyCode

The debug is now

CodeX= 0
MyCode= 0

If that is correct, I am in debt to you. I looked at examples but I guess it is assumed you will have the IMPLICIT NONE. At this point, I don't want to add it as I fear it will not compile or work as intended. I may re-factor the program in the future, but for now I just want to add a few functions to bring it up to date.

(Edit: I looked at his code and he doesn't use functions anywhere. AT ALL. Instead he uses subroutines everywhere and just makes all his variables global.)

[jimdempseyatthecove]

 >>I don't want to add it as I fear it (IMPLICIT NONE) will not compile or work as intended.

Unless the code is explicitly written with non-interchangeable types (same bit pattern) the program will not work as intended even though it may compile ok and produce results assumed to be correct.

As you've seen by your simple example in post 1 that incorrect results are obtained, then consider what happens with a program consisting of 100's to 1000's of procedures where at least one return value is implicitly incorrect yet has been assumed correct. Note, this does not matter if the program has been running like this for many years. Errors are still errors.

Jim Dempsey

[sindizzy]

The original dev checked his results and they seemed to be within reason. However he did not follow best practices so am inclined to leave it as-is and patch it with new functions. That is until it can be refactored.

[DavidWhite]

I would strongly suggest that as soon as possible you start using IMPLICIT NONE.

It quickly finds errors like

INTEGER I1

II = 5

The compiler will pick up that II is not defined.  Otherwise, you can continue for hours trying to find out why I1 never has the correct value.

[JohnNichols]

As noted in the earlier post

(Edit: I looked at his code and he doesn't use functions anywhere. AT ALL. Instead he uses subroutines everywhere and just makes all his variables global.)

----------------------------------------------------------------------------------------------------------------------------------------------

I have been in court many times giving evidence as an expert witness. A witness who does stuff like this and makes even minor mistakes is a gift for the opposing lawyer.  A good lawyer can take two minor mistakes and make an expert look like a very poor engineer or scientist.  

Yes, I have had that pleasure. 

Last week in a court case the bailiff said afterwards, you are very good, I said I have been taught by legal experts what not to do.  

It has been an expensive education for some of my clients when I got it wrong.  

You should always look to the best practices and that is not global variables without implicit none. 

The people who say this ......... has never happened to me, are likely correct, it is just when it does happen it hurts a lot.  

[sindizzy]

Not my code. I inherited and it is too far down the line to be changed so significantly . At some point we will refactor.

[sindizzy]

I am going to not alter his code as it is quite complex and IMLPLICIT NONE would take me forever to correct the logic. I know this because I tried that in another one of his programs and it caused havoc. At some point we will refactor the code but for now we just want to patch it with a couple of new functions.

[JohnNichols]

It sounds like a sound choice.