[csw-maintainers] Calling statvfs() on my home directory

Maciej (Matchek) Blizinski maciej at opencsw.org
Wed Apr 21 14:26:45 CEST 2010


While debugging a failed OpenCSW package build on my workstation I
came across a problem with statvfs() returning EOVERFLOW.  I did some
experiments, and ended up writing the following example code, which
makes a dummy statvfs() call and reports whether it has succeeded or
not.  I've compiled it in two versions, the sole difference being -m32
vs -m64.  Here's the complete code:

$ cat statvfs-example.sh
cat > statvfs-example.c <<EOF
#include <stdio.h>
#include <stdlib.h>
#include <sys/statvfs.h>
#include <errno.h>

int main(void) {
  struct statvfs buf;
  extern int errno;
  if (statvfs(getenv("HOME"), &buf) < 0) {
    printf("statvfs() has failed, errno = %d\n", errno);
    switch (errno) {
      case EOVERFLOW:
        printf("EOVERFLOW\n");
        break;
    }
  } else {
    printf("statvfs() completed successfully.\n");
  }
  exit(EXIT_SUCCESS);
}
EOF

for word_length in 32 64; do
  cc \
    -m${word_length} \
    statvfs-example.c \
    -o statvfs-example-${word_length}
  file statvfs-example-${word_length}
  ./statvfs-example-${word_length}
done

Running it yields the following:

$ bash statvfs-example.sh
statvfs-example-32:     ELF 32-bit LSB executable 80386 Version 1
[FPU], dynamically linked, not stripped
statvfs() has failed, errno = 79
EOVERFLOW
statvfs-example-64:     ELF 64-bit LSB executable AMD64 Version 1 [SSE
FXSR FPU], dynamically linked, not stripped
statvfs() completed successfully.

It looks like any 32-bit binary making the statvfs() call on my home
directory will fail with EOVERFLOW, while a 64-bit binary will
succeed.

Does that count as an advantage of building 64-bit binaries?


More information about the maintainers mailing list