🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

2 total messages Started by Daniel R. Levy Tue, 25 Feb 1986 00:15
Fix for three f77 I/O bugs
#318
Author: Daniel R. Levy
Date: Tue, 25 Feb 1986 00:15
122 lines
4607 bytes
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!levy
Re: Fix for three f77 I/O bugs
#319
Author: Daniel R. Levy
Date: Fri, 28 Feb 1986 19:43
35 lines
2627 bytes
<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
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads