Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 29 Jun 2015 11:11:03 -0400
From: Rich Felker <>
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.


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.