This is the mail archive of the
libc-alpha@cygnus.com
mailing list for the glibc project.
Re: struct stat
Geoff Keating wrote:
> > Why is dev_t a 64-bit integer type?
>
> I think it became 64 bits when it was changed from 16 bits, which was
> way too small.
>
> It won't help anyway. If anyone changed the stat structure in future,
> ino_t and nlink_t would probably both change to 64 bits (I think the
> new NFS wants 64-bit inode numbers).
True enough. My concern is with the present, however. Should there
be support for backward compatability? Certainly Linux doesn't use
all 64 bits.
> > 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.
>
> I suggest __LONG_LONG_NOT_SUPPORTED. In the future, all standard C
> compilers will support 'long long' (by definition, because the
> standard will require it). Certainly it shouldn't be conditioned on
> __GNUC__, because there are many compilers that support it.
Exactly. I have no problem with this.
> How hard would it be to add 'long long' to your research compiler?
> Usually these things are very easy to do if you don't mind the
> generated code being inefficient.
It shouldn't be too hard to add support. As long as the guard on dev_t
can be changed to allow it. :)
-Dave