This is the mail archive of the
libc-alpha@cygnus.com
mailing list for the glibc project.
Re: struct stat
Andreas Jaeger wrote:
> David> The problem is not so much with u_quad_t per se, it's a problem
> David> with the way __dev_t is defined. It's defined as a u_quad_t but
> David> __dev_t (or dev_t as in the man pages) must be an integral type
> David> to allow comparison. This doesn't happen when using non-gcc
> David> compilers.
>
> You're right - dev_t is the problem but dev_t is just `typedef
> __u_quad_t __dev_t'. Therefore we're solving the same problem;-).
Not if the typedef is changed. :)
> I'm not sure if *quad_t needs to be integral but dev_t should be.
Right.
> David> At worst, you can do what the linux kernel guys suggest and use
> David> a long with a second long after the struct for padding when not
> David> compiling with gcc.
>
> But this might cause problems when the kernel enlarges dev_t.
> Currently it's just 16bit on ix86 but AFAIK there have been plans to
> use a 64bit datatype and then your approach will fail since all 64
> bits would be significant.
Yes, absolutely. Clearly this is a short-term solution, and the kernel
guys presented it as such.
> David> The best way to do this (I think) is to just guard the use of
> David> long long with _HAVE_LONG_LONG_ or something similar. Then
> David> the user could just past _D_HAVE_LONG_LONG_ in the compile flags.
> David> The problem is that __GNUC__'s granularity is too large.
>
> __GNUC__ is really meant only for gcc. If you're using a different
> compiler, either the fallback (the struct) or something compiler
> specific has to be used for now.
The problem is, the fallback is downright broken (at least for __dev_t).
How would one use something compiler-specific?
> David> As I said, the problem is really with __dev_t, not u_quad_t.
> David> stat.st_dev must be of a type that can be compared for equality.
>
> But how should this done portably with future kernel enhancements in
> mind? I personally don't like the padding.
Neither do I. It's kludgey at best. But I think we need a solution
for this problem, and soon.
-Dave