[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.11.1506291924390.27295@monopod.intra.ispras.ru>
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.
