Date: Mon, 18 Jun 2007 01:24:39 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: Tim Kientzle <kientzle@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, Colin Percival <cperciva@freebsd.org> Subject: Re: cvs commit: src/lib/libarchive archive_read_open_fd.c archive_read_open_filename.c Message-ID: <20070618082439.GD96936@elvis.mu.org> In-Reply-To: <46760F7A.8020209@freebsd.org> References: <200706180036.l5I0asac023540@repoman.freebsd.org> <4675DFC8.8060108@freebsd.org> <46760F7A.8020209@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Tim Kientzle <kientzle@freebsd.org> [070617 21:52] wrote:
>
> Note that the second call returns a new file position
> that's exactly 0x2f800 bytes beyond the former file
> position, even though nothing has actually happened.
>
> I think any of the following would be reasonable behaviors:
> * lseek() could return ESPIPE ("illegal seek")
> * lseek() could return an unchanged file offset
> (indicating that the file position was unchanged by
> the attempted seek).
> * lseek() could return ENOTSUP ("unsupported operation")
> As I said though, I just don't know that code well
> enough to propose a fix.
ENOTSUP seems to be the most "correct", although I sort of
see it being the equivelant of dispaching a sign saying
"bump" along the highway without actually fixing said
bump. :(
--
- Alfred Perlstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070618082439.GD96936>