[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 29 Jun 2015 11:11:03 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: fseek EOVERFLOW
On Mon, Jun 29, 2015 at 05:51:05PM +0300, Alexander Monakov wrote:
> On Mon, 29 Jun 2015, Justin Cormack wrote:
> > The sign extension is correct - the argument to fseek is off_t (and so
> > is the return value, it is not an int), and off_t is always 64 bit on
> > Musl. For glibc it depends if it is compiled with LARGEFILE_SOURCE.
>
> No; please consult the documentation. The 'offset' argument to fseek is
> 'long', and the return value is 'int' (either -1 on error, or 0).
I think Justin was referring to this:
> (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.
Rich
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.
