Re: struct stat

[Andreas Jaeger <aj@arthur.rhein-neckar.de>]

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

Please note that I CC'ed libc-alpha@cygnus.com instead of bug-glibc
since I'd like to move the discussion to that list.

Andreas

 > Thanks!

 >                                        -Dave

 > ---Original posting to linux-kernel---

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


-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de