forums.silverfrost.com

[Zach]

I am a little afraid to ask this, however:

program banana
integer::n
print*,'The Result'
do while(n < 4)
n = n + 1
print*,n
end do
print* !This line
read *
end program banana

When "This line" is missing, nothing at all is printed
Why is that so?

[Kenneth_Smith]

You need to assign an initial value to n before entering the DO WHILE / END DO loop.

When n = �undefined�, n = n + 1 is also �undefined�.

Compiling the program using Checkmate would have identified the undefined state of n at run time.

[wahorger]

The code

[Zach]

#include <stdio.h>
int main()
{
int n;
do
{
n = n + 1;
printf("%d",n);
}while(n < 4);
}

Adding to something undefined, results in something else undefined, sounds very logical. But, indeed adding a starting value, removes the problem. However, in C the problem does not arise.

[Kenneth_Smith]

The Fortran standard clearly says that the default value of a Fortran variable is UNDEFINED.

You must not to rely on the 0 initialization you may experience using some Fortran compilers; while this is convenient these compilers are not behaving correctly and this can cause havoc when you switch compilers.

It is possible to specify an initialization value in the declaration of a variable, e.g.

real :: a = 0.0

but you have to be careful when such an initialization is performed in a procedure because in that case the initialization is performed only the first time you call the procedure and, in the next, the variable assumes the save attribute. In other words, if the value of a is changed by the end of the first call to the procedure, it has this value (and not zero) at the beginning of the second call.

[Zach]

In my casus as posted
program banana
integer::n
print*,'The Result'
do while(n < 4)
n = n + 1
print*,n
end do
print*
read *
end program banana
There is no initial value to n, but a print below the loop brings out the prints within the loop. This baffles me.

[wahorger]

Zach,

If you wish that FORTRAN was like "C", your wish will never be fulfilled. The rules are different. The syntax is different. Some things are easy to do in FORTRAN, some things are easy to do in "C". I happen to like both for what they can do, and they do work well together!

That being said:
"C" guarantees that static or dynamic (stack) variables are initialized to zero.

FORTRAN does not.

You may find a version/vendor of FORTRAN that does guarantee the value of uninitialized memory, but it is the exception rather than the rule.

Memory that is not intentionally initialized may/will contain any value possible. I am thankful for the compiler messages about using an uninitialized variable; it has saved me numerous times from tracking down bugs due to uninitialized memory issues.

It is simple; if you wish to play in this arena, get used to the rules. Rather than questioning why something appears to work a certain way when you do not obey the rules, abide by the rules, see what happens, and then comment.

[Zach]

Bill, I can understand that Fortran doesn't like uninitialized variables. And that, I shall bear in mind, henceforth. However, you do not seem to have understood my question: rather than assume negative attitudes on my behalf, for which you had no cause. In the case in hand, the compiler, having executed a loop - without printing - depending on the statements that follow the loop, goes back and prints what it didn't print before. That was the issue that I found mind boggling. I think know-why is as important as know-how hence my reluctant rooky question, fearful of harvesting responses like yours.

[Kenneth_Smith]

The behaviour you observe indicates that the memory location the program is using to store the value n was filled with zeros by the program that previously used this location.

[Zach]

Yes stuff lurking in memory might indeed cause unpleasant surprises, but not, given sequential execution, going back to statements, supposedly already dealt with. Not unless the compiler goes back and forth like a scrubbing brush dealing with several statements at a time.

[JohnCampbell]

Zach,

Your statement "do while(n < 4)" says that the loop operation is dependent on the initial value of n, so it needs an initial value to get a predictable result.
Depending on what compiler options you provide to FTN95, the initial value of n in your program can be different, especially /undef, /check or /optimise will give significantly different results.

Depending on your compiler option, using "print*" can/could change the initial value of n. As n is undefined, if the (random) initial value of n is >= 4, no print of n value will be given. ( changing the code often results in changes to undefined variable errors )

You may not like a "negative attitude", but failure to provide an initial value of n does not conform to the F95+ standards and so the results from your program are unpredictable.

[Kenneth_Smith]

Zach,

It is not productive to pursue the question �why�, after it was established that the code is not aligned with the rules of Fortran.

In pursuing this, you are drawing incorrect conclusions from your observations of the program output at runtime and as a consequence making extremely erroneous and misleading statements and speculative claims about the performance of FTN95.

In the context of this relatively simple program there is no issue with FTN95.

When the code follow the rules, and n is explicitly initialised to zero, the code runs correctly with FTN95 Win32, FTN95 X64, gFortran and IFort. This is not the case where n is not explicitly initialised to zero, and this should not be expected (since the code does not follow the rules).

When you compile the code with Checkmate, you can step through the code line by line using the Debugger. You will discover that this exercise confirms the correct serial execution of the code.

[wahorger]

Kenneth, thanks for the additional confirmation.

Well put.

[Zach]

Thank you all for participating in the discussion. Much appreciated. Patrick.