Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Does this code demonstrate a bug in GFortran?

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
like image 737
EnthusiastiC Avatar asked Apr 23 '26 15:04

EnthusiastiC


1 Answers

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.

like image 150
francescalus Avatar answered Apr 28 '26 00:04

francescalus



Donate For Us

If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!