levy@ttrdc.UUCP (Daniel R. Levy) (02/25/86)
Here are fixes for three apparently long-standing f77 I/O library problems
in SysV f77 (and I think in BSD 4.2 and earlier--can't speak for 4.3--
someone sent me mail indicating that at least one of these was fixed in
4.3):
Problem 1.
Formatted floating-point input crashes (or indicates incorrect
input if iostat= or err= is used) when it reads 'E-format'
input data which uses an uppercase 'E'. (Lowercase 'e' works
just fine.)
Repeat by:
program foo
real a
integer io
read (5,10,iostat=io)a
10 format(e5.1)
write(6,*)a,io
stop
end
$ foo
1.2e4 <typed by user>
1.200000000e+04 0 <output by program>
$ foo
1.2E4 <typed by user>
1.20000005 115 <output by program>
<program will crash with core dump if iostat= is not indicated>
Diagnosis and Fix:
The input processing is failing to recognize 'E' (and 'D') as
valid alternates to 'e' and 'd' in formatted input. The fix:
In /usr/src/lib/libI77/rdfmt.c, approximately line 145
[function rd_F()] change
if (*sp=='d' || *sp=='e') { sp++; } else nfrac-=scale;
to
if (*sp=='d' || *sp=='e' || *sp=='D' || *sp=='E' )
{ sp++; } else nfrac-=scale;
Problems 2 and 3.
Explicit error checking for formatted internal input is broken in
two ways. If an err= or iostat= clause is specified in the
read statement, an error is indicated or a nonzero iostat variable
returned if the data read was correct (consistent with the format
statement used). If the data read was incorrect, then the program
will die with a core dump despite the explicit error checking
which was indicated in the Fortran program.
Repeat by:
program bar
integer i
character*2 cbuf
10 format(a)
20 format(i2)
read(5,10)cbuf
read(cbuf,20,iostat=io)i
write(6,*)i,io
stop
end
$ bar
12 <typed by user>
12 2 <output by program>
<note: on a 3B2, the error code will return as a large negative number.
This example was done on a 3B20. I don't know about vaxen.>
$ bar
ab <typed by user>
fmt: read unexpected character
apparent state: unit 5 named
last format: (i2)
lately reading sequential formatted internal IO
abort - core dumped <output by program>
Diagnoses and Fixes:
In the first problem (error returned even though input was correct)
a value is being returned to the Fortran program from a C function
that does not bother to return a value (!). The fix:
In /usr/src/lib/libI77/iio.c, insert a 'return(0);' statement
at the end of the function z_rnew() [approximately line 27].
(It also would be a good idea to insert a similar statement at
the end of the function z_wnew() [same file] but who checks for
write errors in internal I/O?)
For the second problem (error checking from Fortran program is
ignored, program crashes anyhow), the external pointer 'elist'
to the current error-status table is never updated from the
Fortran program! The result is either garbage or the table
from a previous external read or write. This table, which is
passed by address from the Fortran program in routine s_rsfi(),
is supposed to indicate, among other thing, whether the Fortran
program is trapping errors for the I/O operation. The fix:
In /usr/src/lib/libI77/iio.c, approximately line 31, in the
function s_rsfi(), the sequence
if(n=c_si(a)) return(n);
reading=1;
should be changed to (one line added):
if(n=c_si(a)) return(n);
elist=(cilist *)a;
reading=1;
--
------------------------------- Disclaimer: The views contained herein are
| dan levy | yvel nad | my own and are not at all those of my em-
| an engihacker @ | ployer or the administrator of any computer
| at&t computer systems division | upon which I may hack.
| skokie, illinois |
-------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
vax135}!ttrdc!levylevy@ttrdc.UUCP (Daniel R. Levy) (02/28/86)
<Oh oh here it comes. Watch out boy, it'll chew you up! \ Oh oh here it comes. The LINE EATER! [Line eater]> In article <757@ttrdc.UUCP>, levy@ttrdc.UUCP (I) wrote: >Here are fixes for three apparently long-standing f77 I/O library problems >in SysV f77 (and I think in BSD 4.2 and earlier--can't speak for 4.3-- >someone sent me mail indicating that at least one of these was fixed in >4.3): >[bug examples and fixes for SysV f77 I/O] Since posting this, I have gotten communication from Donn Seeley indicating that no such fix can be found in BSD4.3 as far as he can tell. Also please see my caveat 'I _think_ in BSD 4.2'. I can't vouch for the cause in BSD systems, though a couple of BSD 4.(<3) systems I have tried (one on a VAX 11/780 at the University of Illinois, another an emulation [Eunice] of BSD4.1) are obviously guilty of the SYMPTOMS of mishandling internal I/O that I demonstrated in my 'bar' example. I made a poor choice of words when I said it was _fixed_ in 4.3 -- rather, I should say that it WORKS OKAY in 4.3, not that the FIX ITSELF was made under 4.3. (That is, the problem, formerly present in at least some of BSD 4.(<3), has been banished--therefore it is a 'fixed' problem, and the code which constituted the fix has obviously been included in 4.3, probably since the beginning.) I hope you will forgive me for the poor semantics of my message. I hope this will clear up any misunderstandings. Far as I can tell, if you are on a BSD 4.3 system, you have nothing to worry about wrt internal f77 I/O error trapping, from what I am told by Seeley. -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, vax135}!ttrdc!levy
jerry@ucbopal.BERKELEY.EDU (Jerry Berkman) (03/01/86)
Dan Levy posted three bugs: 1) 'D' and 'E' may not be used for 'd' and 'e' in formatted input 2&3) Explicit error checking for formatted internal input is broken in two ways. These have already been fixed in 4.3 BSD, as has numerous other bugs in formatted I/O. - Jerry Berkman Computing Services, (415) 642-4804 jerry@opal.Berkeley.EDU