Re: libc/1068: [glibc] Possible erroneous return code from Linux __getdirentries

[Jamie Lokier <jamie.lokier@cern.ch>]

Andreas Jaeger wrote:
> Jamie>  I'm not convinced.  Shouldn't *basep still be set in this case?
> Jamie>  It was before.
> 
> *basep is set by the caller and since we return an error, we don't
> have to modify it.  I don't see a problem with this.

Uh-oh.  More bugs.

>From the code, I'd assumed *basep was not set by the caller.

The documentation is different to the code, and the code
is different for different ports in Glibc.

The Linux & Unix versions allow basep to be NULL.
When it is not NULL, the incoming value in *basep is ignored, though it
is set to the new offset at the end.

The Hurd version does not allow basep to be NULL.  It faults if it is.
The incoming offset does appear to be used.

So there are two bugs, in addition to the error code thing.

  1. Incoming value of *basep is ignored on Linux & Unix.
     Documentation says incoming value of *basep is starting position.

  2. NULL basep is permitted on Linux & Unix, but explicitly disallowed
     on Hurd.

Allowing NULL is nice because it allows the lseek() calls to be elided
(see my other patch), which can be a significant performance
improvement.

If it's decided that NULL basep shall be allowed, to allow eliding
the lseek() call, then should readdir & readdir_r be changed to
use NULL basep?

-- Jamie