Re: FreeBSD Fortran Failure

["Zack Weinberg" <zackw at stanford dot edu>]

On Sun, May 13, 2001 at 01:23:13PM -0700, Mark Mitchell wrote:
> >>>>> "Toon" == Toon Moene <toon@moene.indiv.nluug.nl> writes:
> 
>     Toon> Then I first have to have an idea where the abort is
>     Toon> *really* happening.  Is there an error message involved ?
>     Toon> Can you show a traceback in gdb ?
> 
> The problem comes in the second call to l_read, coming from this code:
> 
>       read(90, *, end=10) j
> 
> On GNU/Linux, the second call to lread exits quickly becuase the call
> to GETC near the beginning of the routine returns -1.  On FreeBSD, it
> doesn't -- it returns a sparc character, followed by the number `2'.
> So, we exit that loop, and go to the `rddata' loop.
> 
> I think that the reason for this might be that GETC is defined in
> terms of stdio, and ftruncate operates on file descriptors.  So, if
> the stdio buffer isn't flushed by the call to ftruncate, there could
> still appear to be characters present.  Is that possible?

I think so.  The code does

   loc = ftell(bf);
   fseek(bf, 0L, SEEK_END);
   if (no need to truncate)
     return;
   fflush(bf);
   ftruncate(fileno(bf), loc);

At this point, stdio's idea of the file position does not match the
kernel's, and nothing resynchronizes it.  I bet another 
fseek(bf, 0L, SEEK_END) right after the ftruncate would do the trick.

-- 
zw     Breeding replacement security officers on farms where giant robot
       combine harvesters operate would tend to increase the evolutionary
       selection pressure, which may be the desired effect.
       	-- David G. Bell