This is the mail archive of the
libc-alpha@cygnus.com
mailing list for the glibc project.
Re: struct stat
Mark Kettenis wrote:
> At worst, you can do what the linux kernel guys suggest and use
> a long with a second long after the struct for padding when not
> compiling with gcc.
>
> This is really bad, since that means you're changing the ABI. Right
> now the linux kernel may only be using a 32-bit device numbers, but in
> the future it may very well start using 64-bit numbers, because the
> number of supported devices becomes to big to fitin a 32-bit integer.
> Having a 64-bit dev_t in glibc makes it possible to do this waithout
> having to recompile all user apps. With the hack suggested to you by
> the kernel folks this will no longer be true. I strongly advise you
> not to do this.
I wasn't planning to, actually. That's why I said "at worst." :)
> The best way to do this (I think) is to just guard the use of
> long long with _HAVE_LONG_LONG_ or something similar. Then
> the user could just past _D_HAVE_LONG_LONG_ in the compile flags.
> The problem is that __GNUC__'s granularity is too large.
>
> We're just being conservative. We know of no other compiler that
> supports long long.
Fine. But shouldn't the headers work for compilers we have NOW?
It seems to me that designing something for the future that breaks
lots of things now will prevent us from ever getting to that
future. :) At least, with anything but gcc.
> We're using the Edison front end which can support "long long"
> if the feature compiled into the compiler. I'm not sure that
> it sets any macros when this is done. Hence my suggestion for
> a generic guard that is user-settable.
>
> Please check if it sets a preprocessor symbol. If there is one we
> will probably add support if the compiler in question is not too
> esoteric. If there is no such symbol, you should make a request to
> have such a flag added.
The compiler is going to be too esoteric because it's our research
prototype compiler. I don't want to force special cases just to
support US. :)
> lcc I think has no support for long long, so it would be nice
> to have an alternative, even if it means using padding.
>
> If that's true, we cannot support lcc. We depend on 64-bit integer
> in several places, e.g. to support large files. This will be more and
> more important in the future when disks get bigger and bigger.
This is flat-out wrong, IMHO. Restricting users to gcc cuts out a whole
lot of users from linux. I'm thinking specifically of the entire
academic
research community. :(
-Dave