This is the mail archive of the libc-hacker@cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: not a nice patch


> Reply-To: drepper@cygnus.com (Ulrich Drepper)
> From: Ulrich Drepper <drepper@cygnus.com>
> Date: 10 Feb 1999 12:00:28 -0800
> 
> I had to change one more type for 32bit Intel systems: ino64_t.  It used
> to be 32 bits since this is what I was initially told is enough.
> Nowadays (which NFSv3, CODA) we need to have 64 bit inode numbers.  Oh
> well.
> 
> Fortunately the type is hardly used directly so far.  The only use
> will be in stat64.  Here we have some padding which I was able to take
> out so that the struct len is the same.
...

It's also used in `struct dirent64' on my machine, which would change
size.  I imagine that versioning can be used to fix this.

struct dirent64
  {
    __ino64_t d_ino;
    __off64_t d_off;
    unsigned short int d_reclen;
    unsigned char d_type;
    char d_name[256];
  };

Since it's a reliability issue, can it go in 2.1.1?  Then there won't
be many programs that were compiled with the old version.

Hmmm.  Won't there be lots of programs that just use 'ino_t', and so
get the inode number truncated to 32 bits anyway?

-- 
Geoffrey Keating <geoffk@ozemail.com.au>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]