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

[Roland McGrath <roland at frob dot com>]

> No, it's not.  If you would define the code in sysdpes/posix as that
> which can be implemented using POSIX functions the directory would be
> empty.

Don't be silly.  It's obvious that the entire POSIX system cannot be
circularly defined in terms of itself, but that is wholly beside the point.

> No, this is not what I mean.  There is no danger because everybody who
> honestly ports glibc to a new system will check this.  It is nothing
> you can overlook easily for the very same reasons you reject this
> code.

Ahem.  You may notice that I just now discovered this code and complained
about it, though it was written that way months (years?) ago.

> > 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.
> 
> These kernel versions are not supported.

(Any more.)  But they serve as existence proofs that such a system can
exist and have a libc port to it, thus making the issue potentially arise.

> > If you don't have pthreads then why would you expect to have pread at all?
> 
> Because these functions can be used in other code which does not use
> them for the thread-safetiness of the interface.  It's simply a nice
> interface which suits in many situations.

Well, I suppose, if people are writing non-threaded programs so as not to
be portable to pre-1003.1-1996 systems.  Any program attempting to be even
a little portable will already cope with lack of a pread and be just fine
if we give a stub that an autoconf check will recognize.

> > 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.
> 
> As said above, it's a useful interface and therefore might be used in
> places you won't expect it.  I don't know where it is in the moment.
> Unless the same application is using threads there shouldn't be any
> danger.

I prefer to avoid the subtle bugs and horrifying race condition debugging
sessions beforehand by ruling out the ways people will obviously shoot
themselves in the feet, rather than redressing them after the fact when the
poor hacker and all his hapless users has marched 14 months on bloodied
feet before figuring out what the problem was.

It is already the case that someone could well write a program using some
other user-level threading package (or cthreads on the hurd) and use pread
because it's there, and be scrod and likely not be so clever as you and me
to figure out what is happening to him.