Silverfrost Forums

Welcome to our forums

error 112 while I did initialize integer with -2139062144

3 Mar 2016 11:20 #17281

Hi all,

'm not terribly experienced at fortran-coding (3~4 weeks under my belt for fortran; i've done more matlab-scripting before this) but I have the feeling I encountered an error that shouldn't be there (i.e. rather a source-code error or similair)

at a specific integer number, i get an 112 error (which said I did not initialize the variable), while I did initialize that specific number. The following code contains this problem (very simplified). I tried updating silverfrost but that didn't help ('PLATO version 4.7.0'). I'm on a windows 8.1 machine (64-bits) if anyone wants to know

program why_doesnt_it_work

implicit none

integer::i

i=-2139062143

print*,i

i=-2139062145

print*,i

 

i=-2139062144  

print*,i   

!the previous two integers got printed, but at this point, I initialize the variable 'i' with the new number, but when called upon in line 10 it says: !'error112,reference to undefined variable, array element of function result (/UNDEF)' - ' main -  in file mfd.f95 at line 10 [+0151]'

end program why_doesnt_it_work 

I encountered the problem while I did a loop over all integers [do i=-huge(i),huge(i)] to check if a function worked properly for all integers. In this do-loop, I entered the integers one-by-one into a function, and the error occured only in the function (and not in the main program that contained the do-loop). Only for a specific integer, value -2139062144 did the problem occur (as shown in code above; the other two integers work just fine)*

However, the problem does seem a bit hit-and-miss, as in different codes that error did not always appear (although the code shown above consistently hits that error on my computer)

I hope you could give me some guidance/assistance/insight with respect to that weird error

RagD

*note, since the do-loop couldn't get past -2139062144, I did not check if this problem also occurred at higher values

3 Mar 2016 12:26 #17282

As you are using Plato, try using different compile options: Release Win32 Debug Win32 CheckMate Win32

You will find only the last fails, as -2139062144 is used to indicate an undefined value. The last opting includes /undef

That's the way it works !

John

3 Mar 2016 12:46 #17283

oh, wow, thanks, that works.

just wondering; how do those other compiling options reference to an undefined number? With an external bit that defines the variable to be set? And/or are there any other unexpected traps I can expect when doing a loop over all the integers or reals?

RagD

3 Mar 2016 11:37 #17284

In general, the 80 (hex) pattern is used for ANYTHING to indicate it is 'undefined'. Including real/doubles/etc. When encountered, if /CHECKMATE is being used, you'll get the trap. But, if you compile and run as /RELEASE, no problem.

I have code that creates these patterns nearly every time it runs, so I cannot run in /CHECKMATE if I'm doing anything other than a quick run to check out a change.

C1, I1, L1 = 80 I2, L2 = 8080 I4,R4,L4 = 80808080 .....

Please login to reply.