struct stat
Andreas Jaeger
aj@arthur.rhein-neckar.de
Thu Apr 1 00:00:00 GMT 1999
>>>>> David Greene writes:
David> On 12 Mar 1999, Andreas Jaeger wrote:
>> >>>>> David A Greene writes:
>>
>> > I originally sent this to linux-kernel. I've snipped bits
>> > from the thread there. I hope this problem can be resolved
>> > ASAP.
>>
>> > Passing -D__GNUC__ to the compiler is not a solution, since
>> > that macro brings in a lot of non-standard gcc-isms.
>>
>> > Can someone reply to this so that I know the problem is
>> > being looked into? We need a solution for this.
>>
>> We need a 64 bit integral type for u_quad_t. Since long long isn't in
>> any standard so far (it should be in ISO C9X), we can't rely on it.
David> I understand that. But is u_quad_t supposed to be an integral type?
David> A struct certainly isn't.
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;-).
I'm not sure if *quad_t needs to be integral but dev_t should be.
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.
>> Could you send us a code snippet that defines a 64 bit unsigned and a
>> 64bit signed integral type with the correct compiler identification
>> macros? For example, for gcc you would just do:
>>
>> #ifdef __GNUC__
>> typedef unsigned long long int __u_quad_t;
>> typedef long long int __quad_t;
>> #endif
>>
>> So, how would you do this with your compiler?
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.
David> We're using the Edison front end which can support "long long"
David> if the feature compiled into the compiler. I'm not sure that
David> it sets any macros when this is done. Hence my suggestion for
David> a generic guard that is user-settable.
David> lcc I think has no support for long long, so it would be nice
David> to have an alternative, even if it means using padding.
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.
Hopefully some other glibc developer has some fresh ideas;-).
Cheers,
Andreas
--
Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de
for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de
More information about the Libc-alpha
mailing list