[comp.sys.sgi] f77 REWIND bug

jeffb@aquifer.geology.uiuc.edu (Jeffrey Biesiadecki) (03/22/91)

Hi -

We are having trouble with the f77 "REWIND" statement on our 4D/20 {TG,G}
and our 4D/25 TG running IRIX 3.3.1.

We have a program that writes output to a file.  It is convenient to look at
that file from another window while the program is running.  Sometimes, the
program has reason to "REWIND" the output file, and start writing over it
from the beginning.  Here's the bug:  if there is less stuff written to the
file after the REWIND than there was before the rewind, then the extra data
stays in the file until it is closed.

I've tried using the ENDFILE statment, and that didn't seem to help, and
other options for the OPEN statment (such as SHARED) but those didn't help
either.  One fix is to close and reopen the file after the REWIND, but
hopefully there is a less kludgy way to solve our problem.

I'm not sure what the Fortran 77 standard says about this behavior, but it
doesn't seem to happen on other machines that we run the program on.  Here's
a sample program:

------------------------------------------------------------
      program rewbug
c
c  program that illustrates rewind bug
c
      open (1,file='afile')
      write (1,*) 'this is the first line of afile '
      write (1,*) 'this is the second line of afile'
c
      rewind 1
      write (1,*) 'this should be the only line now'
      call flush (1)
c
c  when the pause statement is reached, look at 'afile' from another window,
c  or press CTRL-Z and look at afile.  only after the program continues is
c  the junk at the end of 'afile' (the second line) cleaned up.
c
      pause
      close (1)
c
      end
------------------------------------------------------------

Thanks for any suggestions you may have,
Jeff
--
/*******************************************************************************
** Jeff Biesiadecki               ** University of Illinois, Urbana-Champaign **
** jeffb@aquifer.geology.uiuc.edu ** Depts. of Geology and Computer Science   **
*******************************************************************************/

calvin@dinkum.wpd.sgi.com (Calvin H. Vu) (03/24/91)

It sounds like a bug.  It's surprising nobody has reported it before.  
The I/O library should truncate the physical file [i.e. not just the
internal representation of it inside the library] to the current file pointer
position if the first I/O statement after a REWIND/BACKSPACE is a WRITE.
It will be fixed in our next release.  Meanwhile I can't think of anything 
better than using your workaround or by calling a wrapper to the C function
truncate() to give the file a zero length after the REWIND i.e.  something 
like this would also work:

      program rewbug
c
c  program that illustrates rewind bug
c
      open (1,file='afile')
      write (1,*) 'this is the first line of afile '
      write (1,*) 'this is the second line of afile'
c
      rewind 1
      call trunct('afile')
      write (1,*) 'this should be the only line now'
      call flush (1)
c
c  when the pause statement is reached, look at 'afile' from another window,
c  or press CTRL-Z and look at afile.  only after the program continues is
c  the junk at the end of 'afile' (the second line) cleaned up.
c
      pause
      close (1)
c
      end


and a C routine  for a wrapper:

void trunct_(filename, len)
	char *filename;
	int len;
{
	static char *buf;
	static int oldlen;
	if (!buf || oldlen < len) {
		buf = (char *) malloc(len+1);
		oldlen = len;
	}
	strncpy(buf, filename, len);
	buf[len] = '\0';
	truncate(buf, 0);
}


Oh well, it's even messier than your workaround only it should be much
speedier.

Thanks  for the consise report and the workaround.

- calvin
--
-----------------------------------------------------------------------------
Calvin H. Vu			   | "We are each of us angels with only one
Silicon Graphics Computer Systems  | wing.  And we can only fly embracing
calvin@sgi.com   (415) 962-3679	   | each other."