Comment author: gabelevi

Assuming that there are valid fds which are greater than or equal to FD_SETSIZE

Since FD_SETSIZE is pretty low (1024), this should be a safe assumption. It's probably the common case too, though I think EINVAL is still non-standard for this case.

Comment author: @dra27

Passing an fd which is >= FD_SETSIZE is undefined behaviour. Can we not usefully do the simplest patch, which is just to return EBADF instead of EINVAL in all cases? It sounds like in Lwt's case, this would result in a reasonable course of action (filtering out the fd)?

Comment author: @dra27

Open Group reference: http://pubs.opengroup.org/onlinepubs/9699919799/functions/select.html

Comment author: gabelevi

My guess is that almost everyone who gets Unix.Unix_error(EINVAL, "select", "") has too many fds open and is passing in some valid fd >= FD_SETSIZE. Since the behavior for fds < 0 or >= FD_SETSIZE is undefined, it might be best for developer ergonomics to throw a descriptive exception that doesn't overlap with anything that select() might throw.

I suppose EBADF won't necessarily fix the Lwt case, since valid fds >= FD_SETSIZE won't be filtered out with their fstat check.

Comment author: gabelevi

Of course, changing the exceptional behavior might be a breaking change for anyone relying on it...

Comment author: @dra27

Well, I think we could refine it that having an fd >= FD_SETSIZE means either that you are leaking fds or you should be using poll. With that in mind, another idea could be to raise Invalid_argument for the >= FD_SETSIZE case (and not care about whether the fd is actually valid in this case), but that could only be done if we add a function like can_select of type file_descr list -> bool.

It's worth cross-referencing #1514 (#1514), as we recently rejected changing Unix.select to be implemented using poll.

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.