Re: struct stat

[David Greene <greened@eecs.umich.edu>]

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.

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

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

As I said, the problem is really with __dev_t, not u_quad_t.
stat.st_dev must be of a type that can be compared for equality.

                                  -Dave