struct stat

David A. Greene (greened@eecs.umich.edu)
Thu, 11 Mar 1999 17:18:25 -0500

We've run into a problem with the definition of struct stat
that appears in kernel 2.0.36 and later (or maybe it's a libc6
problem). Specifically, st_dev is declared as a __dev_t, which
under gcc is a typedef of "long long." However, under any
other compiler (i.e. one that does not define __GNUC__), it is
a typedef of a struct containing an array of two integers:

from <gnu/types.h>:

#ifdef __GNUC__
typedef unsigned long long int __u_quad_t;
typedef long long int __quad_t;
#else
typedef struct
{
long int __val[2];
} __quad_t;
typedef struct
{
__u_long __val[2];
} __u_quad_t;
#endif
typedef __u_quad_t __dev_t; /* Type of device numbers. */

Perhaps this is a libc6 problem, but it seems the kernel is
very closely connected in this case. I saw hints to this
problem in the linux-kernel archives (there was some discussion
about coordination between the kernel and libc teams).

Our problem, though, I think is somewhat different. When we
use lcc to compile, say, the Spec95 benchmark suite, it emits
compile-time errors in the builds of gcc and perl. These
two benchmarks compare st_dev for equality, and we all know
that it is illegal in C to compare two structs.

If a 64-bit device number is desired, why not declare it
"long long" explicitly? Why all this hiding behind __GNUC__?
Just say what you want and let the compiler implement the
non-standard type. Declaring it as a struct breaks code that
was written years ago. At least with "long long," the compiler
has a resonable chance of being updated to support it.

If there is a solution to this problem, please direct me to the
proper information.

Thanks!

-Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/