This is the mail archive of the libc-alpha@cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: struct stat


>>>>> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]