[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150629153127.GD32532@port70.net>
Date: Mon, 29 Jun 2015 17:31:27 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: fseek EOVERFLOW
* Rich Felker <dalias@...c.org> [2015-06-29 11:11:03 -0400]:
> On Mon, Jun 29, 2015 at 05:51:05PM +0300, Alexander Monakov wrote:
> > (I hit this issue due to using fseek with size_t offsets and SEEK_SET: on
> > 32-bit, my offsets in range 2G-4G were sign-extended, leading to failure with
> > unclear diagnostics)
>
> Sign extension is the wrong word here; rather, it's coercion of an
> unsigned 32-bit type into a signed 32-bit type, which is a valid
> implicit conversion but doesn't do what you want. After the value
> becomes negative, what happens is just like what would happen if you
> had intentionally passed a negative value. I'm not sure why the
> kernel's not catching it as invalid, but I'm also not sure what we
> would do to fix things up if it doesn't... It's not easy to treat
> negative offsets as invalid from userspace except in the special case
> of SEEK_SET; for the others, userspace can't see that the result is
> going to be negative.
this affects lseek conformance too:
[EINVAL]
The whence argument is not a proper value, or the resulting
file offset would be negative for a regular file, block
special file, or directory.
[EOVERFLOW]
The resulting file offset would be a value which cannot be
represented correctly in an object of type off_t.
and then in the rationale:
An invalid file offset that would cause [EINVAL] to be returned
may be both implementation-defined and device-dependent (for
example, memory may have few invalid values). A negative file
offset may be valid for some devices in some implementations.
The POSIX.1-1990 standard did not specifically prohibit lseek()
from returning a negative offset. Therefore, an application was
required to clear errno prior to the call and check errno upon
return to determine whether a return value of (off_t)-1 is a
negative offset or an indication of an error condition. The
standard developers did not wish to require this action on the
part of a conforming application, and chose to require that
errno be set to [EINVAL] when the resulting file offset would
be negative for a regular file, block special file, or directory.
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.
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.
