This is the mail archive of the
libc-alpha@cygnus.com
mailing list for the glibc project.
Re: struct stat
Mark Kettenis wrote:
>
> 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.
Linux uses 16 bits now. I can see going to 32 bits. But how soon will
it approach the need to use 64 bits?
And I'm still curious how glibc's 64-bit st_dev interfaces with Linux's
16-bit st_dev/16-bit padding.
> 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.
But the struct is just plain wrong. st_dev is supposed to be integral.
> 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.
Yes, I noticed that, which is why I made the comment that his views were
extreme. But Mr. Calahan does have a point, even if it was stated
badly.
> 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.
I would like to hear your interpretation.
> 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.
Ok, I'll wait for that. There are plenty of other things to do. :)
> 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.
Ok, thanks for the tip!
> 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.
Fine. As I said, that patch would only be to add long long support for
compilers other than gcc. It's too bad that no one seems to want to
support ANSI C compilers, though.
I will send a fresh message when I feel I have the time to sit down and
create a patch. Which sources should I use, and where can I get them?
-Dave