This is the mail archive of the
libc-alpha@cygnus.com
mailing list for the glibc project.
Re: struct stat
Date: Mon, 15 Mar 1999 16:27:37 -0500
From: "David A. Greene" <greened@eecs.umich.edu>
I'm a little fuzzy in this area. Why would this break binary
compatability? Yes, you'd lose information if all 64 bits are
important, but for the time being on Linux/x86, you don't. Linux
(in asm/stat.h) defines st_dev as a short with some padding (actually
only a short's worth of padding). How does this work with glibc? I'm
not being sarcastic here, I'm really curious as to how this works.
The magic words are ``for the time being''. At the moment Linux/x86
starts using a wider st_dev, and believe me it will, you'll need the
extra bits that glibc provides. When that happens, some small changes
to libc's internals will be sufficient to fully support the new
kernel. No recompilation of your applications will be necessary. If
however try to ``solve'' your problems by using padding, your
applications will break since they don't look at the now significant
information in the padding. In fact the current way we handle
u_quad_t by defining it to be a struct if no 64-bit integer type is
available is a way to privide the padding, without letting you make
the mistake mentioned above.
Actually, the response from one fellow was "and tell the glibc
developers not to go and define types without talking to us," or
some such thing. Though I think his comment was a bit extreme,
and does not represent the views of the kernel guys.
Yeah, that comment came from Albert D. Calahan, a known glibc hater.
One of the other people taking part in the discussion that was taking
place in the kernel mailing list clearly dissiociated himself from
Calahans remarks.
However, the general consensus on linux-kernel (at least from those who
participated in the thread) is that glibc is broken.
That's not how I interpret the discussions, but we are probably both biased.
Ok, I can work within the system. I just want to make sure I'm not
wasting my time. Assuming I make a sane patch (are there explicit
instructions for this?), follow all the coding standards, etc. will it
be accepted? I'd like to get an authoritative answer if possible.
The authoritative answer will have to come from Ulrich Drepper, the
glibc maintainer.
BTW, the patch would change the uquad_t guard to
__GNUC__ || __LONG_LONG_SUPPORTED__. I will do no more than this,
as I don't get any sense of anything more being accepted.
You'll also want to do something similar for __int64_t and __uint64_t,
further down.
Anyway, if you really want to get something like this in, I advise you
to send a fresh message to libc-alpha explaining you'd like to see an
option like this (generic support to force the compiler to use long
long if it isn't automatically detected such as in the case of gcc),
and if you can, provide a patch. Do not question the fact that dev_t
is 64-bits, this is non-negotiable, and would only diminish your
chances of getting your changes accepted. For similar reasons, do not
question the fact that we define u_quad_t as a struct if we're not
sure if a 64-bit type is available.