On Mon, Nov 30, 2020 at 6:10 PM Scott Cheloha <scottchel...@gmail.com> wrote:
> On Sat, Nov 28, 2020 at 01:41:50PM -0800, Philip Guenther wrote: > ... > > After thinking through states more, #4 isn't safe: _fwalk() can't take > > sfp_mutex because it's called from __srefill() which has its FILE locked, > > which would reverse the order: two concurrent calls to __srefill() from > > line-buffered FILEs could have one in _fwalk() blocking on locking the > > other, while the other blocks on the sfp_mutex for _fwalk(). > > This part in __srefill(): > > /* > * Before reading from a line buffered or unbuffered file, > * flush all line buffered output files, per the ANSI C > * standard. > */ > ... > Where in the standard(s) is this behavior required? I'm not even sure > how to look for it. > Pick a version of the C standard and search for "buffered" until you find something like this, which is part of 7.19.3p3 in the draft I'm looking at: <...> When a stream is line buffered, characters are intended to be transmitted to or from the host environment as a block when a new-line character is encountered. Furthermore, characters are intended to be transmitted as a block to the host environment when a buffer is filled, when input is requested on an unbuffered stream, or when input is requested on a line buffered stream that requires the transmission of characters from the host environment. Support for these characteristics is implementation-defined, and may be affected via the setbuf and setvbuf functions. Effectively the same text appears in the POSIX standard in XSH 2.5p6. Basically, you're allowed to stop doing that by instead printing out your cell-phone number so that everyone who wants to complain that their program failed to output its prompt before blocking for input can call and scream at you. :D Philip Guenther
