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.