Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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.