sysdeps/posix/{pread64,pwrite64}.c
Roland McGrath
roland@frob.com
Wed Jan 5 16:45:00 GMT 2000
> First, the LFS proposal will probably be adopted for the next revision
> of the Unix standards and since it'll be merged with POSIX the latter
> will also have it.
But it don't yet. Anyway, the rationale for sysdeps/ layout is not for
definitional purism, it's for convenience of porting and sharing code.
> Second, I see this rather as POSIX-like function should be used.
> POSIX does not demand that all of the functions it includes are
> defined on all systems and therefore you cannot write functions in
> sysdeps/posix as if all interfaces are available.
That sounds like a contradiction of your first argument. Indeed, that you
cannot expect lseek64 to be available is exactly my (first) complaint and
reason that sysdeps/posix code should not use it.
> > I think it is dangerously misleading to provide an incorrect
> > implementation instead of none at all.
>
> I don't see a danger here.
Ha! You are not that naive. The nature of the danger is introduction of
subtle race condition bugs when noone suspects the issue may have arisen.
> If you have a system with threads you better have a pread syscall (or
> equivalent).
Is it not the case that there are Linux kernels where linuxthreads can work
but there is no pread? I'm pretty sure that was the case at one time, anyway.
> If you don't have threads the replacement is not too bad.
If you don't have pthreads then why would you expect to have pread at all?
It's certainly not a portable expectation.
> If you really want to see this removed I wouldn't object strongly but so
> far I have no seen a convincing argument.
Well, you know me; I made the old college try at the theroetical reasons
first, but I only really care about the pragmatic issue that something is
now broken in 2.1 for the hurd. (I already implemented pread/pwrite for
the hurd in 2.2, but left new features out of 2.1 as seemed proper.)
Something else I haven't tracked down yet appears to have newly changed so
the bogus pread is being linked in where it wasn't before, and I haven't
looked into what it is yet.
More information about the Libc-hacker
mailing list