[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reflection and /proc
Scott Lurndal writes:
> In article <7bq1i4$ast7g@fido.engr.sgi.com>, you write:
>> We might let lseek() be limited on 32-bit hardware, but the other
>> two are still important. I think FreeBSD made lseek() work right
>> on 32-bit hardware.
>>
>> I just checked their web site. FreeBSD only supports lseek().
>> Since I know FreeBSD supports huge files and there is no mention of
>> a size-related error, it seems to me that they have a 64-bit lseek().
>
> As may be. As it happens, I originally championed a scheme
> to utilize the existing interfaces (open, lseek, read, write, stat),
> etc. with 64-bit off_t and size_t fields where appropriate during
> I originally wanted to do something very similar
> to the EFT (expanded fundamental types) program which was part of
> the SVR4.0 base delivery which changed various fundamental types
> like the size of pid_t, uid_t, gid_t (16 to 32 bits), et. al.
We need to do this anyway for ino_t and a few others. We might as
well also do ssize_t, size_t, and off_t.
> The problem was that not all systems
> were based on SVR4, so many didn't have the infrastructure
> in place to allow graceful migration to larger off_t (and even
> SVR4 was missing some things).
The libc developers claim that they can change anything at all.
They have some kind of symbol versioning that lets them keep the
old API and new API together in one library.
-
Linux-future: thinking about the future of the Linux kernel
Archive: http://humbolt.nl.linux.org/lists/
Wish list: http://users.ox.ac.uk/~mert0236/linux-future.html