Date: Mon, 29 Jun 2015 19:43:17 +0300 (MSK) From: Alexander Monakov <amonakov@...ras.ru> To: musl@...ts.openwall.com Subject: Re: fseek EOVERFLOW On Mon, 29 Jun 2015, Rich Felker wrote: > On Mon, Jun 29, 2015 at 05:31:27PM +0200, Szabolcs Nagy wrote: > > the kernel side should fix this.. unless they consider > > /dev/zero a special device where netative offset is valid, > > and work correctly on regular files. > > > > if lseek is conforming then i think fseek would work too. > > I missed that it was operating on /dev/zero. I suspect the kernel > considers all offsets (negative and positive) valid for /dev/zero. > Obviously this makes the return value of the lseek syscall ambiguous > (is it an error value or a small negative number?) so I think, if this > is the case, it's a bug that should be fixed on the kernel side. Well, /dev/zero was there only for the sake of making a small testcase; my actual failure was with a /proc/<pid>/mem file, but I guess the same reasoning applies. If I make the test work on a "real" file (a 4G unallocated file on a tmpfs), and compile with -m32 (plus -D_FILE_OFFSET_BITS=64 on glibc, otherwise fopen fails), the kernel returns EINVAL. I think the bit I was missing is that libc implementations expect the kernel to always fail SEEK_SET lseek for offsets with high bit set. Thanks. Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.