[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