Date: Mon, 23 May 2016 14:36:58 +0200 From: Dirk Engling <erdgeist@erdgeist.org> To: "<freebsd-hackers@freebsd.org>" <freebsd-hackers@freebsd.org> Subject: Re: read(2) and thus bsdiff is limited to 2^31 bytes Message-ID: <5a607409-1b98-8944-b1f2-4422b1d28248@erdgeist.org> In-Reply-To: <20160523122131.GC8747@britannica.bec.de> References: <b2515cae-b75d-66e9-4207-3cf100ab3ab0@erdgeist.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5a607409-1b98-8944-b1f2-4422b1d28248>