[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: header file mismatch for struct statfs and linux
From: |
Chris Friesen |
Subject: |
Re: header file mismatch for struct statfs and linux |
Date: |
Mon, 11 Nov 2002 14:36:17 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 |
Andreas Schwab wrote:
Chris Friesen <address@hidden> writes:
|> The glibc header file for struct statfs defines the following fields:
|>
|> __fsblkcnt_t f_blocks;
|> __fsblkcnt_t f_bfree;
|> __fsblkcnt_t f_bavail;
|>
|> where __fsblkcnt_t is defined as:
|>
|> typedef unsigned int __fsblkcnt_t;
|>
|> This causes problems since the linux kernel (and "man statfs") defines
|> these entries as type long.
On architecture where int == long this does not make any difference. On
ia64 at least the type is correctly defined.
My point is not the size, but the signedness. If I do
bool fsavailable = (statfsbuf.f_blocks > 0);
then because userspace headers use unsigned int while the kernel uses
straight longs, the filesystem will always appear to be available even
when it isn't.
|> As well, I believe POSIX says that they are supposed to be longs.
POSIX does not define statfs nor <sys/statfs.h>, and it requires
fsblkcnt_t to be an unsigned integer type, but nothing more.
Okay, my bad. I had looked at the man pages for statfs on a number of
other OS's and they led me to believe it was a POSIX thing. Chorus,
BSD, Linux, Irix, and HP-UX man pages all list the field type as "long".
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: address@hidden