This is the mail archive of the
libc-alpha@cygnus.com
mailing list for the glibc project.
Re: struct stat
Mark Kettenis wrote:
> Look, there is a little piece of code in gnu/types.h (the #else clause
> for __GNUC__, in fact) that defines dev_t as a struct for non-gcc
> compilers. Why can't this guard be moved into the definition of struct
> stat, and for non-gcc compilers, define st_dev as a long int and follow
> it with padding? Yes, it's ugly, yes, it doesn't support 64 bits (but
> nether does Linux), but it's more correct than something that doesn't
> even compile.
>
> That would break binary compatibility. As far as glibc is concerned
> all 64 bits are important.
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.
> Better yet, coordinate with the Linux folks and come up with a solution.
>
> I believe that that was done when the decision was made to make dev_t
> a 64-bit type. Anyway, they'll probably just tell you that a compiler
> that does not support a 64-bit integer type is plain broken.
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.
However, the general consensus on linux-kernel (at least from those who
participated in the thread) is that glibc is broken.
> Good Lord, is it really this complicated? I have to go, download the
> source, create a patch and submit it? Couldn't one of the libc
> developers do this much more easily? Where do I get the "latest"
> sources anyway (i.e. which version should I patch against?)?
>
> That's the most reliable way to get your problems fixed. It's the way
> how the free software community works.
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.
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.
> > They should try to convince somebody else to do it, e.g. pay somebody
> > to do the job.
>
> Isn't that what I'm trying to do? :)
>
> Yes, but so far you're not very successful.
I noticed. No reason to rub it in. :)
Unfortunately, your response here is not very helpful.
> Irrelevant. There are Linux compilers out there that are ANSI C and
> they don't work. That's wrong.
>
> They work if you restrict yourself to ANSI C (that is only use ANSI C
> library calls). dev_t is a POSIX extension!
Does POSIX define long long as a standard type? I'm pretty sure it
requires dev_t to be an integral type, which it is not without gcc.
I assume it does not require dev_t to be 64 bits, but please correct
me if I'm wrong.
Does POSIX extend the C language? I was not aware of that.
> > Yep, that's intentional, since gcc is the only compiler available to
> > use that has a 64-bit integer type.
>
> Wrong, it's the only compiler YOU know of.
>
> Sorry, typo, I meant avaiable to US (the glibc developers).
Understandable. Can we add support for other compilers?
> Can you point me to such a library for Linux? A library that's freely
> available the same way glibc is?
>
> The sources for the old Linux C library (libc5) should be still be
> available, since binaries are still distributed. Try Debian or
> RedHat. But I must warn you. Compiling them yourself is not easy and
> I'm not sure any effort was made to make it usable with any other
> compiler than gcc.
i.e. it has the same problems as libc6. This is not helpful. :(
> Binary compatibility is more important to us than source
> compatibility. Of course standards compliant programs (ANSI, POSIX)
> should compile cleanly on a reasonable compiler. Our defenition of a
> reasonable compiler is one that has a 64-bit integer type if you want
> to use extensions to ANSI C.
I don't want to use extensions to ANSI C. glibc does.
-Dave