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