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 <>
Subject: fseek EOVERFLOW


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;


I observe the following results:

- on musl, the argument (-1) is sign-extended for syscall, and no failure is

- 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

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:

    [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)


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.