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 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.