Re: struct stat

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

Mark Kettenis wrote:
> 
>    Date: Sat, 13 Mar 1999 13:40:14 -0500
>    From: "David A. Greene" <greened@eecs.umich.edu>
> 
> OK, let's get some things straight.  To use all features in glibc 2
> and linux 2.2 you need a 64-bit integer type.  The types quad_t and
> u_quad_t are abstractions for such a type (just like int64_t and
> uint64_t).  Since dev_t is an unsigned  64-bit integer type in the
> glibc ABI, it is defined in terms of u_quad_t.  

Why is dev_t a 64-bit integer type?

> If you are using a compiler that does not support a 64-bit integer 
> type, you'll lose in certain cases.  One of such cases is when you 
> try to compare two dev_t's.  Fortunately there are not too many 
> programs that actually do that.  

I'd say perl and gcc are pretty important programs, though.  libc is
broken.  dev_t is supposed to be an integral type.  Period.

> If you use stat() but never actually make a comparison against
> the st_rdev member.  Your program will compile and work correctly
> because of the definition of u_quad_t as a struct.

Absolutely.  No argument there.  But this is irrelevant.

> Right now gcc is the only compiler that we now of that supports a 64-bit
> integer type.  This implies that if you want to compare two dev_t's
> you have to use gcc.

I still think this is just wrong.  Why must dev_t be a 64-bit type
anyway?
Which O.S.'s actually use all 64 bits?

> If there is another compiler that supports a 64-bit integer type,
> which is available for enough people outside a specific research group
> or company, we'll add support for it.

Not too likely in our case, I'm afraid.  Would it be too much to ask
for the guard on quad_t/uquad_t to be changed from __GNUC__ to 
__LONG_LONG_SUPPORTED__ or something?  Then at least other compilers
have 
a chance.  This seems like a fair compromise to me.

> In your case, where your compiler is only used in your research group,
> I suggest that you just modify `/usr/include/bits/types.h' such that
> it correctly defines u_quad_t as a 64-bit integer type.  This should
> not be very hard, and if you keep your patches as diffs to the
> origional files it should be easy to reapply them when you update your
> copy of glibc.

This will work, but what about all those other poor souls who are going
to run into the same problem?

> The bottonline is that some features will never be available on
> compilers that do not have a 64-bit integer type.  

But well-defined, core O.S. features on a common 32-bit processor?  This 
is not realistic.

> If you want to keep using older compilers that do not support such a 
> type, and depend on features which are implemented in glibc 2 by using 
> such a type, you shoud stick with older versions of the C library.  For 
> Linux this means libc5.

So your answer is, "Sorry, you can only use gcc.  Which should be fine,
because why would anyone use anything else anyway?"

And the compiler is not depending on features in glibc2.  The software
being compiled is depending on the C library to do sane things.

> By the way, since you keep mentioning __dev_t, I must warn you that
> all symbols with a double underscore are reserved for internal use in
> the library.  You should never use them in your programs, so always
> use dev_t, and also try to use that name in discussions to avoid
> setting bad examples.

I keep mentioning __dev_t because that is what I see in <gnu/types.h>.
Sorry.

                                            -Dave