Re: [Chicken-hackers] Fix attempt for bug #1269 "Port or reader state corruption"

[Kooda]

On Fri, 25 Mar 2016 19:15:30 +0100,
John Cowan wrote:
> Kooda scripsit:
> 
> > So at exit() time,
> > the file descriptor associated with the source file will get lseek-ed
> > to match the position in the FILE* buffer.
> 
> That of course will not work on unseekable devices such as a tty or pipe,
> and is not what happens, at least in normal libcs: instead, fflush(NULL)
> is done.

Unseekable devices don’t show the erroneous behaviour in the first
place, since it’s caused by a seek performed by the libc. So, we don’t
care about them here.


> > Unfortunately, POSIX only documents the behaviour of fflush(NULL) for
> > *output and update streams*. Input streams stay untouched. See here:
> > http://pubs.opengroup.org/onlinepubs/9699919799/functions/fflush.html
> 
> Flushing an input stream is meaningless.  If stdio buffering has read
> more of the input than has been consumed, there is no way to push
> the unconsumed output back into the file. (There is ungetc, but it
> is only guaranteed to work with one character.)  Indeed, the effect
> of fflush(some_input_stream) is undefined, or even if you are trying
> to fflush an input/output stream when the last operation was an input
> operation.
> 
> > - Calling fflush() on every input file owned by CHICKEN before calling
> >   fork(). 
> 
> As noted above, this is meaningless.

Please read the link you just quoted. It says the following:

“For a stream open for reading, if the file is not already at EOF, and
the file is one capable of seeking, the file offset of the underlying
open file description shall be set to the file position of the stream,
and any characters pushed back onto the stream by ungetc() or
ungetwc() that have not subsequently been read from the stream shall
be discarded (without further changing the file offset).”

It doesn’t seem meaningless or undefined to me.


> Note however that atexit functions are only best-effort.  They are
> not called if the process is dying on a signal.  If an atexit function
> function does something bad, such as calling exit() as opposed to _exit()
> in an attempt to prevent further exit processing, or calling longjmp()
> in an attempt to abort the exit, earlier atexit functions may never
> be invoked.
> 

Indeed, that’s why I posted my patch in the first place. It’s not
ideal but it shouldn’t be too much of a problem as a first solution.

Though as sjamaan noted on IRC, we should probably try to stay
coherent and completly replace any call to exit() to a call to _exit()
so that the same behaviour always appears.