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.