This is the mail archive of the
libc-alpha@cygnus.com
mailing list for the glibc project.
Re: struct stat
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.
Better yet, coordinate with the Linux folks and come up with a solution.
Failing that, at least reduce the granularity of the guard around
uquad_t, as discussed below.
> > However, since I'm not the only glibc developer you'll have to
> > convince some of the others too.
>
> Ok, so what's the best way to do this?
>
> Send a clean patch to the libc-alpha mailing list, that does not break
> the existing support for gcc. Explain the problem you are trying to
> solve. Add a ChangeLog entry. You should probably read the GNU
> coding standards before you do this.
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?)?
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? :)
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.
> 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.
> > 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?
> I see lots of "upcoming" and "future" adjectives. What about the
> present?
> Even when these standards are finished, there should still be some
> support for backward compatability.
>
> Look ahead is one of the principles of a good design. And we cannot
> keep supporting old compilers forever. As I said gcc has had long
> long for a very long time now, and all major 32-bit Unix-like OSes
> have a compiler that supports a 64-bit integer type now.
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.
-Dave