From owner-freebsd-hackers@freebsd.org Mon May 23 12:37:03 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63384B45E76 for ; Mon, 23 May 2016 12:37:03 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from elektropost.org (elektropost.org [217.115.13.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A2AF311BE for ; Mon, 23 May 2016 12:37:02 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: (qmail 36749 invoked from network); 23 May 2016 12:36:59 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with ESMTPS (DHE-RSA-AES128-SHA encrypted); 23 May 2016 12:36:59 -0000 Subject: Re: read(2) and thus bsdiff is limited to 2^31 bytes To: "" References: <20160522225414.GB24398@britannica.bec.de> <154dab43060.11208cdfd132112.2616144627831899155@nextbsd.org> <20160522231203.GB25503@britannica.bec.de> <154db353935.dd5e87c1133922.4370692881788049491@nextbsd.org> <20160523122131.GC8747@britannica.bec.de> From: Dirk Engling Message-ID: <5a607409-1b98-8944-b1f2-4422b1d28248@erdgeist.org> Date: Mon, 23 May 2016 14:36:58 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160523122131.GC8747@britannica.bec.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 12:37:03 -0000 On 23.05.16 14:21, Joerg Sonnenberger wrote: > Atomic meaning in this context that the read can be observed either > completely or not at all. This still doesn't mean that read must > execute the full size. Other cases for short read/writes are socket, > pipes etc. On linux I found read() returning a short read, however I wonder if any user land application developer ever expects a read from local file to yield a short read and continue reading. Maybe I should scan base system sources for all occurrences of read. Best case scenario as found in bsdiff is if (read(fd,old,oldsize)!=oldsize) and I wonder if an API user SHOULD be expecting the short read behaviour at all, just because the nbytes crosses a certain arbitrary threshold. erdgeist