Re: some more JOBS
On Fri, Aug 10, 2001 at 10:29:15AM +0530, Nikunj A. Dadhania wrote:
> Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
>
> > On Thu, Aug 09, 2001 at 04:26:30PM +0530, Nikunj A. Dadhania wrote:
> > > Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
> There is a member of stat structure fsid. its declared as
> typedef __u_quad_t __fsid_t; /* Type of file system IDs. */
>
> and __u_quad_t is declared as
>
> #ifdef __GNUC__
> typedef unsigned long long int __u_quad_t;
> typedef long long int __quad_t;
> #else
> typedef struct
> {
> long __val[2];
> } __quad_t;
> typedef struct
> {
> __u_long __val[2];
> } __u_quad_t;
> #endif
>
> Now stat uses fsid.__val[0]. so while compiling stat says that fsid.__val[0] not the member of the structure.
A compliance note. The version of SUSv2 that I have only defines
the types `struct stat' and `struct statvfs'. `struct statvfs' contains
the the field `unsigned long f_fsid'. It weems like in both both
Linux and Hurd (both using glibc) f_fside has type `unsigned long long'.
I think this might be ok because the standard never specifies the
location of each field within a structure, and `long long' could always
be demoted to `long'.
But stat seems to be using `struct statfs' and statfs() to get it's
information about the filesystem. This seems to me like an upstream
bug.
Igor
Reply to: