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 14:40:25 -0500
From: "David A. Greene" <greened@eecs.umich.edu>
Mark Kettenis wrote:
> Umm...Wait a second. dev_t is supposed to be an integral type. It
> isn't if you're not using gcc. This is broken.
>
> Yep, because your compiler is broken, and it is impossible to fix the
> problem in libc.
Yep, because long long is not a standard type and libc should not
be using non-standard stuff (or should at least support
standard-compliant compilers). libc is broken.
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.
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.
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.
Note that I'm not saying I'm unwilling to put the work in. I'd just
like to optimize the process as much as possible, and it seems the
libc folks could do this much more efficiently. But if it must be
done this way, I'll do it.
> Yes, that's the ideal solution. But what about all those people (most
> of them, actually), who don't want to go near the sources for their
> compiler?
> IMHO, there should be some way to define dev_t for those compilers that
> don't support long long
>
> 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.
But seriously, shouldn't the C library work with C compilers?
> True, but dev_t is one of those features. It should work without
> relying on non-standard types.
>
> On Linux, a 64-bit integer type is considered a standard type. It has
> been in the C compiler that 99.9% of the Linux users use.
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!
> That's not quite true. Guarding uquad_t with __GNUC__ precludes using
> any compiler but gcc.
>
> 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).
> > You wouldn't want to use a compiler that does not have a 64-bit integral
> > type anyway since they will become more and more important in the near
> > future."
>
> "In the future." I need something that works now. :)
>
> Then use a compiler that supports 64-bit integer type, or use a C
> library that does not consider a 64-bit type as a standard integer type.
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 agree that lookahead is important. But so is compatability. And I
never said anything about supporting old compilers forever. When the
new C standard comes out, go ahead and remove the compatability (yes,
I'm reversing my statement above after careful consideration). But
libc should not be relying on compilers to support things in a
standard that is not yet finished.
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.
Mark