bug-glibc
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]