From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97281 invoked by alias); 17 Sep 2018 14:15:37 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 93361 invoked by uid 89); 17 Sep 2018 14:15:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RDNS_DYNAMIC,TVD_RCVD_IP autolearn=no version=3.3.2 spammy=whom, our, permanently X-HELO: brightrain.aerifal.cx Date: Mon, 17 Sep 2018 14:15:00 -0000 From: Rich Felker To: Florian Weimer Cc: GNU C Library Subject: Re: Sticky EOF breaks stream concatenation via dup2 [BZ #23636] Message-ID: <20180917141517.GH17995@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker X-SW-Source: 2018-09/txt/msg00238.txt.bz2 On Mon, Sep 17, 2018 at 03:37:03PM +0200, Florian Weimer wrote: > Do we have to revert the fix fpr bug 1190 (which introduces sticky > EOF for stdio streams)? > > We received a bug report that cups-filters is quite broken due to > this change, and while reviewing the libio sources, I found evidence > that what cups-filters does (dup2-ing another descriptor after EOF) > was once considered supported (in _IO_new_file_underflow): > > fp->_IO_read_end += count; > if (count == 0) > { > /* If a stream is read to EOF, the calling application may > switch active > handles. As a result, our offset cache would no longer be valid, so > unset it. */ > fp->_offset = _IO_pos_BAD; > return EOF; > } > > Usually, when our own testing finds bugs, that's that's just a small > subset of what the larger user community (many of whom cannot > recompile their applications) will experience once they upgrade, so > I'm quite worried about the implications of the fix for bug 1190. I've always considered dup2'ing to temporarily or permanently switch the fd underlying a FILE to be reasonable usage, since it's something that needs to be doable (especially for the standard streams, which can't be replaced) and freopen has multiple fatal flaws that make it unsuitable to the task. However this does not absolve the appliction of a requirement to clear the EOF status if the stream might be at EOF when switching. Failure to do so is an application bug that was masked by the glibc bug. Rich