As you can see from the code below, when it asks you whether to carry on or stop the program, by pressing other keys like ";" or "," it reads it as if you had pressed the "Y" or "y" key but you didn't. So, I'm asking whether this is a bug in the compiler, or a problem with the code?
program vols
!Calculates difference in volume of 2 spheres
implicit none
real :: rad1,rad2,vol1,vol2
character :: response
do
print *, 'Please enter the two radii'
read *, rad1,rad2
call volume(rad1,vol1)
call volume(rad2,vol2)
write(*,10) 'The difference in volumes is, ',abs(vol1-vol2)
10 format(a,2f10.3)
print *, 'Any more? - hit Y for yes, otherwise hit any key'
read *, response
if (response /= 'Y' .and. response /= 'y') stop
end do
end program vols
!________________________________________________
subroutine volume(rad,vol)
implicit none
real :: rad,vol,pi
!calculates the volume of a sphere
pi=4.0*atan(1.0)
vol=4./3.*pi*rad*rad*rad
!It's a little quicker in processing to do r*r*r than r**3!
end subroutine volume
Without more details on your exact input we cannot conclude that this is a bug in gfortran. Instead, there is a feature of the program which may lead to "confusing" behaviour.
For getting the response, the program uses list-directed input. This leads to non-intuitive results. For example, for someone writing a calculator there may be surprise about what happens when someone enters * or /.
In the calculator example, * is involved in repeat counts and / in record separators. For this question , also has a special meaning. In list-directed input , is a value separator and read *, x presented with that character doesn't set x to the value ','.
Instead, the input statement
read *, response
when presented with input
,
will come to the , and see "hah, the user is telling me that there's no value specified". This contrasts with the empty line, where input processing continues to wait for a value.
This value separator couples with another feature of list-directed input: null values are allowed. A null value completes the input statement but leaves the corresponding value unchanged (not set to blank).
This means that if the input goes like
1 1
y
1 1
,
On the second pass, the character response is unchanged from the value 'y'. Equally, for
1 1
,
response is unchanged from its undefined status: the program isn't allowed to compare its value with 'y'.
How to address this? Simply use an appropriate format:
read '(A)', response
In this way, input , is treated as a character not as a value separator.
Although commas are treated in a special way in the list-directed input of the question, semicolons are not. If you see unexpected behaviour with a semicolon input then that could be a cause for concern. I don't see that happen with the gfortran available to me.
However, semicolons may be special. When the decimal edit mode is COMMA (rather than the default POINT), then a semicolon is treated as a value separator instead of a comma (which now acts as a decimal separator in values such as 1,23). COMMA is not the default mode of a connection.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With