This is the mail archive of the
libc-alpha@cygnus.com
mailing list for the glibc project.
Re: struct stat
Mark Kettenis wrote:
> Why is dev_t a 64-bit integer type?
>
> I explained that in one of my previous mails. Anywoy, since the width
> of dev_t is part of the ABI, it's set in stone now :-).
Ok, I can understand that.
> I'd say perl and gcc are pretty important programs, though. libc is
> broken. dev_t is supposed to be an integral type. Period.
>
> libc is NOT broken. Your compiler is. You're blaming libc for doing
> the best it can to support your broken compiler. Should we just
> generate an error?
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.
> I still think this is just wrong. Why must dev_t be a 64-bit type
> anyway?
> Which O.S.'s actually use all 64 bits?
>
> I don't know, but most probably Linux in a few years.
The key being, "in a few years." Why can't we make it work NOW? :)
> > If there is another compiler that supports a 64-bit integer type,
> > which is available for enough people outside a specific research group
> > or company, we'll add support for it.
>
> Not too likely in our case, I'm afraid. Would it be too much to ask
> for the guard on quad_t/uquad_t to be changed from __GNUC__ to
> __LONG_LONG_SUPPORTED__ or something? Then at least other compilers
> have a chance. This seems like a fair compromise to me.
>
> That's reasonable, but the condition should of course be __GNUC__ ||
> __LONG_LONG_SUPPORTED__ since we know for sure that GCC supports it.
Yes, of course. :)
> 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?
> This will work, but what about all those other poor souls who are going
> to run into the same problem?
>
> They should really fix their compiler to support 64-bit integer types
> and give us the opportunity to check this support at compile-time (by
> providing proper preprocessor symbols for us to check).
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.
> > The bottonline is that some features will never be available on
> > compilers that do not have a 64-bit integer type.
>
> But well-defined, core O.S. features on a common 32-bit processor? This
> is not realistic.
>
> Well my 32-bit processor has instructions to deal with 64-bit
> quantities. And libc does not provide only core OS features.
True, but dev_t is one of those features. It should work without
relying on
non-standard types.
> So your answer is, "Sorry, you can only use gcc. Which should be fine,
> because why would anyone use anything else anyway?"
>
> My answer is "Sorry you can only use a compiler with a 64-bit integral
> type. Right now the only one for Linux I know of is gcc.
That's not quite true. Guarding uquad_t with __GNUC__ precludes using
any compiler but gcc.
> 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. :)
> I bet you cannot use your compiler with large files on Solaris 2.6 either.
>
> And the compiler is not depending on features in glibc2. The software
> being compiled is depending on the C library to do sane things.
>
> Which it does. Look at Unix98 and the upcomming new ISO C standard.
> They demand a 64bit integral type to be there.
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 bacward compatability.
All IMHO, of course.
BTW, I think the libc team is doing an excellent job, overall. The
switch
to libc6 on Linux was a godsend. I'm just trying to help make it
better. :)
-Dave