Re: struct stat

[Mark Kettenis <kettenis@wins.uva.nl>]

   Date: Fri, 12 Mar 1999 17:00:40 -0500 (EST)
   From: David Greene <greened@eecs.umich.edu>

   On 12 Mar 1999, Andreas Jaeger wrote:

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

   I understand that.  But is u_quad_t supposed to be an integral type?
   A struct certainly isn't.

u_quad_t is supposed to be a 64 bit integral type if a 64 bit integral
type is available.

   The problem is not so much with u_quad_t per se, it's a problem
   with the way __dev_t is defined.  It's defined as a u_quad_t but
   __dev_t (or dev_t as in the man pages) must be an integral type
   to allow comparison.  This doesn't happen when using non-gcc
   compilers.

   At worst, you can do what the linux kernel guys suggest and use
   a long with a second long after the struct for padding when not
   compiling with gcc.

This is really bad, since that means you're changing the ABI.  Right
now the linux kernel may only be using a 32-bit device numbers, but in
the future it may very well start using 64-bit numbers, because the
number of supported devices becomes to big to fitin a 32-bit integer.
Having a 64-bit dev_t in glibc makes it possible to do this waithout
having to recompile all user apps.  With the hack suggested to you by
the kernel folks this will no longer be true.  I strongly advise you
not to do this.

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

   The best way to do this (I think) is to just guard the use of 
   long long with _HAVE_LONG_LONG_ or something similar.  Then
   the user could just past _D_HAVE_LONG_LONG_ in the compile flags.
   The problem is that __GNUC__'s granularity is too large.

We're just being conservative.  We know of no other compiler that
supports long long.  

   We're using the Edison front end which can support "long long"
   if the feature compiled into the compiler.  I'm not sure that
   it sets any macros when this is done.  Hence my suggestion for
   a generic guard that is user-settable.

Please check if it sets a preprocessor symbol.  If there is one we
will probably add support if the compiler in question is not too
esoteric.  If there is no such symbol, you should make a request to
have such a flag added.

   lcc I think has no support for long long, so it would be nice
   to have an alternative, even if it means using padding.

If that's true, we cannot support lcc.  We depend on 64-bit integer
in several places, e.g. to support large files.  This will be more and
more important in the  future when disks get bigger and bigger.

Mark