Re: struct stat

[Geoff Keating <geoffk@ozemail.com.au>]

> Date: Fri, 12 Mar 1999 17:00:40 -0500 (EST)
> From: David Greene <greened@eecs.umich.edu>
> Reply-To: greened@eecs.umich.edu
> cc: "David A. Greene" <greened@zip.eecs.umich.edu>, libc-alpha@cygnus.com
> 
> 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.
> 
> I understand that.  But is u_quad_t supposed to be an integral type?
> A struct certainly isn't.
> 
> 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 not portable.  On some machines, `long long' has to be aligned
to an 8-byte boundary, but two longs need only be aligned to a 4-byte
boundary.

If you really really must do this sort of thing, use 'double'.
Fortunately, only an arithmetic type is required, according to the
standard.  You would have to ensure that inode numbers can't be NaN,
or -0, but this is a very easy thing to check, and it still leaves you
with more possible inodes than you can fit in a 2^64-byte filesystem.

(Of course, you'd use a real `long long' in the kernel and libc.)

-- 
Geoffrey Keating <geoffk@ozemail.com.au>