[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: John Cowan
Subject: Re: [Chicken-hackers] Fix attempt for bug #1269 "Port or reader state corruption"
Date: Fri, 25 Mar 2016 14:15:30 -0400
User-agent: Mutt/1.5.20 (2009-06-14)

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.

> Unfortunately, POSIX only documents the behaviour of fflush(NULL) for
> *output and update streams*. Input streams stay untouched. See here:

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

> - Calling _exit() instead of exit() in the default exit-handler. This
>   would prevent the streams from synchronizing with their FDs but
>   would completely throw away functions registered with atexit() or
>   on_exit()

If you are doing a fork-exec sequence and the exec-family function fails,
you are supposed to call _exit(127) so that your buffers are not flushed
twice by the implicit fflush(NULL) that exit() does.

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.

> - Calling fflush() on every input file owned by CHICKEN before calling
>   fork(). 

As noted above, this is meaningless.

John Cowan        address@hidden
If I have seen farther than others, it’s because my head is sitting
on the shoulders of a giant.  --Trond Engen

reply via email to

[Prev in Thread] Current Thread [Next in Thread]