 |
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
wahorger

Joined: 13 Oct 2014 Posts: 437 Location: Morrison, CO, USA
|
Posted: Sat Sep 30, 2017 9:23 pm Post subject: Run-time bug |
|
|
I encountered what I believe to be an issue with run-time error checking and formatted reads.
Reading a floating point using the 'A' format specifier should yield a run-time error, or an error that can be "trapped" at least.
The following code demonstrates this using both a floating point and a logical and reading with the "A" format specifier. The floating point read works (and gives a weird value, but the logical will throw a run-time error.
Code: |
real abcd
logical my_log
character*32:: buffer='1234.5'
abcd = 0.0
my_log = .false.
read(buffer,'(a)',err=2000,end=1000)abcd
print *,abcd
read(buffer,'(a)')my_log ! this will cause the run time format/data mismatch error
stop
2000 continue
print *,'Error Detected'
stop
1000 continue
print *,'EOF Detected'
stop
end
|
|
|
Back to top |
|
 |
mecej4
Joined: 31 Oct 2006 Posts: 873
|
Posted: Sat Sep 30, 2017 11:05 pm Post subject: |
|
|
I don't think that the Fortran standard is of much use in guiding us as to what should happen, given that the code is non-conforming. This is not one of the few errors that a compiler is required to issue an error message for.
Most compilers, unless asked to check errors, will assume that the programmer has taken care to match format items and I/O list items regarding type. Specifically, the problem is that the A in the format string does not match a character type item in the I/O list, but is used to read a REAL. Thus, whether an error message is to be issued, etc., depends on how much error checking is done.
Regarding the "weird" value of the REAL, here is the explanation. The data is read using the A format, resulting in placing the six characters into memory: '1', '2', '3', '4', '.', .5'. When you print the contents of abcd as a real, only four bytes are used, i.e., '1', '2.', '3', '4'. The hexadecimal representation of the real is thus Z'34333231'. Taking this as an IEEE-32 real gives us the value 1.6688934E-07, which is probably the "weird" value that you mentioned.
You can see this yourself by using the output statement
Code: | write(*,'(1x,Z8)')abcd, transfer(buffer(:4),abcd) |
|
|
Back to top |
|
 |
PaulLaidler Site Admin

Joined: 21 Feb 2005 Posts: 5275 Location: Salford, UK
|
Posted: Mon Oct 02, 2017 7:41 am Post subject: |
|
|
I have tested this code under Win32 and x64 and in both cases I get a runtime exception "Format/data mismatch". I don't think this feature has been added since the last full release but maybe it has.
P.S. Sorry I miss-read the post. I will note the omission. |
|
Back to top |
|
 |
John-Silver
Joined: 30 Jul 2013 Posts: 751
|
Posted: Sun Oct 15, 2017 6:47 am Post subject: |
|
|
Quote: | Most compilers, unless asked to check errors, will assume that the programmer has taken care to match format items and I/O list items regarding type |
... and therein lies the problem.
A compiler should assume that all users are capable of errors in input data (a reality). It's the simple things (error-wise) in life that make a man's daily program writing a misery at times.
'it's got to be something simple' is usually the first thing that springs to mind after a couple of hours trying unsuccessfully to find a bug in a program, and it's usually proven to be the case ... but takes ages to find.
I assume the 'director of error checking' at fortran standards HQ is a certain Mr D.E. Vil , the untiring work of whom is of Dan's frequent acquaintance ! lol |
|
Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|