Re: Code for testing hurdselect.c

[Svante Signell]

On Thu, 2012-10-18 at 11:12 +0200, Richard Braun wrote:
> On Thu, Oct 18, 2012 at 09:13:28AM +0200, Svante Signell wrote:
> > On Tue, 2012-10-16 at 23:40 +0200, Samuel Thibault wrote:
> > > Hello,
> > > 
> > > Svante Signell, le Fri 24 Aug 2012 04:52:15 +0200, a écrit :
> > > > - file descriptors were read, sorted, and the good ones registered.
> 
> Why sorted ? How do you know the "good ones" from the others ?

Of course they don't have to be sorted, only flagged good/bad.
According to the code:
              if (pollfds[i].events & POLLIN)
                type |= SELECT_READ;
              if (pollfds[i].events & POLLOUT)
                type |= SELECT_WRITE;
              if (pollfds[i].events & POLLPRI)
                type |= SELECT_URG;

Remember: This was written a long time ago, why making a big issue of
it?

> > > I have to say I don't understand why doing it. If there is any file
> > > descriptor which is not valid, the whole call has to return EBADF,
> > > that's what POSIX asks.
> > 
> > According to POSIX that is correct for select(). However, I think you
> > missed the line below in my message:
> > Note: Only for the poll case, select was not yet implemented!
> 
> The poll() call was added after select() ...

What do you mean, the poll functionality was added after select in POSIX?

I referred to the code in hurdselect.c:
if (pollfds)
POLL case
else
SELECT case
endif

> The behavior of poll() on elements of
> > fds that refer to other types of file is unspecified.
> > and
> > RETURN VALUE
> >         Upon successful completion, poll() shall return a non-negative
> >         value. A positive value indicates the total number of file
> >         descriptors that have been selected (that is, file descriptors
> >         for which the revents member is non-zero).
> 
> I also still don't see the point.

POSIX does not specify to return EBAFD for the POLL case as for the
SELECT case. That's it.