From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 856 invoked by alias); 30 Apr 2005 02:12:10 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 764 invoked by uid 48); 30 Apr 2005 02:11:51 -0000 Date: Sat, 30 Apr 2005 02:12:00 -0000 Message-ID: <20050430021151.763.qmail@sourceware.org> From: "ncm-nospam at cantrip dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050429155408.21286.ralfixx@gmx.de> References: <20050429155408.21286.ralfixx@gmx.de> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug libstdc++/21286] [4.0/4.1 Regression] filebuf::xsgetn vs pipes X-Bugzilla-Reason: CC X-SW-Source: 2005-04/txt/msg04189.txt.bz2 List-Id: ------- Additional Comments From ncm-nospam at cantrip dot org 2005-04-30 02:11 ------- Just to add... if sgetn() loops reading until it gets n bytes, but underflow() accepts a pipe's short reads, then in_avail() will report the size of the short read. Then, istream::read_some() will rdbuf->sgetn(p,rdbuf->in_avail()), thus matching POSIX pipe semantics when attached to a pipe. (For those who don't know: as long as whoever is writing the other end of the pipe writes no more than PIPE_BUF bytes into it, then POSIX requires that read() deliver the bytes on write boundaries. Thus, if you're writing structs, the reader will see half a struct. If you're writing short-enough lines, the reader will only ever see complete lines -- although you might see more than one. Watch out that PIPE_BUF is 4K or more on Linux, but only 512 bytes on BSD!) It's exciting to finally get this right. With a bit more work, I see now that we might be able to support nonblocking file descriptors, and maybe even zero-copy I/O, too! Thank you, Ralf. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21286