|
Message-ID: <alpine.LNX.2.11.1506291558470.27295@monopod.intra.ispras.ru> Date: Mon, 29 Jun 2015 16:19:36 +0300 (MSK) From: Alexander Monakov <amonakov@...ras.ru> To: musl@...ts.openwall.com Subject: fseek EOVERFLOW Hello, if I run the following test: cat <<EOF >test-fseek.c #include <stdio.h> #include <string.h> #include <errno.h> int main() { FILE *f = fopen("/dev/zero", "r"); int r = fseek(f, -1, SEEK_SET); printf("%d %s\n", r, strerror(errno)); return 0; } EOF I observe the following results: - on musl, the argument (-1) is sign-extended for syscall, and no failure is reported; - on glibc, the argument is sign-extended for syscall (and a syscall is made), but return value 'r' is set to -1 to indicate an error, but errno is not set. It's not entirely obvious to me if (and how) the implementation should diagnose this, but in light of the fact that a syscall is made with a huge 64-bit value as offset, the following seems to apply on 32-bit platforms: [EOVERFLOW] [CX] For fseek(), the resulting file offset would be a value which cannot be represented correctly in an object of type long. (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) Thanks. Alexander
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.