sysdeps/posix/{pread64,pwrite64}.c

sysdeps/posix/{pread64,pwrite64}.c

[Roland McGrath]

I think these are bogus, for several reasons.  They have been there for a
while, but I just noticed because they just started breaking things (I
guess something else is calling them).

Firstly, sysdeps/posix is for functions implemented in terms of POSIX entry
points.  lseek64 is not a POSIX entry point, so a function using it has no
business residing in sysdeps/posix.  

Secondly (and this is a problem with sysdeps/posix/{pread,pwrite}.c too),
the whole point of pread/pwrite is to be thread-safe as opposed to using
lseek.  I think it is dangerously misleading to provide an incorrect
implementation instead of none at all.  If a threaded program wants to use
file descriptors safely, it needs to know that pread/pwrite work as
specified or else that it must do its own synchronization.  In the current
situation, one will believe there is a pread/pwrite but in fact the
specified functionality is not available.

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

[Ulrich Drepper]

Roland McGrath <roland@frob.com> writes:

> Firstly, sysdeps/posix is for functions implemented in terms of POSIX entry
> points.  lseek64 is not a POSIX entry point, so a function using it has no
> business residing in sysdeps/posix.  

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.

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.

> I think it is dangerously misleading to provide an incorrect
> implementation instead of none at all.

I don't see a danger here.  If you have a system with threads you
better have a pread syscall (or equivalent).  If you don't have
threads the replacement is not too bad.  If you really want to see
this removed I wouldn't object strongly but so far I have no seen a
convincing argument.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

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

[Roland McGrath]

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

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

[Ulrich Drepper]

Roland McGrath <roland@frob.com> writes:

> That sounds like a contradiction of your first argument.

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.

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

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.

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

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

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

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

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

[Roland McGrath]

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

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

[Ulrich Drepper]

Roland McGrath <roland@frob.com> writes:

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

But you are not using it on a system which has a really functional
thread implementation.  So I'm still waiting for the reason why it
should fail if you are not using threads.

And for the argument to use another thread implementation: there are
many more problems, pread is the last to worry about.  The libc is
tight closely to the thread library and vice versa that you have to
look through all the code in question and will find this one as well.
I even think that if you do the port correctly and compile the librt
the make check in this directory will sooner or latter fail because of
this.

Fact is that there is and will be systems using glibc without having
threads.  You force the porters to have own copies of the code we now
have in sysdeps/posix for no other reason but that the porters to
complete Unix systems might overlook this broken implementation.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

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

[Ulrich Drepper]

Geoff Keating <geoffk@cygnus.com> writes:

> assume that if glibc compiles, and passes its testcases, then it works.

But it won't pass the test suite for systems with threads.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

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

[Roland McGrath]

> But you are not using it on a system which has a really functional
> thread implementation.

Nor is anyone else using the sysdeps/posix implementations.  What on earth
is your point?  (Anyway, the hurd does have a "really function thread
implementation", as in programs that are multithreaded really work--that
has been the case since before you took over glibc.  What it does not have
is a pthreads implementation, which is a fine reason for people to expect
to cope with not having a pread function in libc 2.1.)

> Fact is that there is and will be systems using glibc without having
> threads.  You force the porters to have own copies of the code we now
> have in sysdeps/posix for no other reason but that the porters to
> complete Unix systems might overlook this broken implementation.

You seem to have forgotten what sysdeps is all about.  Create a
sysdeps/posix/singlethreaded for those systems to use and voila.  As I said
in the first place, the primary complaint is about the incorrect placement
of the code and only the secondary complaint is about its bogus content.
Anyway, what is this mythical glibc port that has no pthreads but is not hurd?
And what in heaven could make a future port an argument about what to put
in the 2.1 branch?!?