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

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


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

Re: sysdeps/posix/{pread64,pwrite64}.c


> 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.

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