Re: [PATCH] don't overlay storage selecting on big fd

[gr...@apache.org]

Jeff Trawick wrote:
> FD_SET is rather unfriendly if you give it a file descriptor that is >= 
> FD_SETSIZE.  It will overlay storage.

> Any comments?  Yeah, the error code sucks.  APR_ENOPOLL?  APR_ENOSOCKET?

What's wrong with APR_EBADF?  That give me a good hint of what the problem is
without having to grep/Google/look stuff up.

Greg

> +#if !defined(WIN32) /* socket sets handled with array of handles */
> +    if (fd >= FD_SETSIZE) {
> +        /* XXX invent new error code so application has a clue */
> +        return APR_EBADF;
> +    }

Re: [PATCH] don't overlay storage selecting on big fd

[Jeff Trawick <tr...@attglobal.net>]

gregames@apache.org wrote:
> Jeff Trawick wrote:
> 
>> FD_SET is rather unfriendly if you give it a file descriptor that is 
>> >= FD_SETSIZE.  It will overlay storage.
> 
> 
>> Any comments?  Yeah, the error code sucks.  APR_ENOPOLL?  APR_ENOSOCKET?
> 
> 
> What's wrong with APR_EBADF?  That give me a good hint of what the 
> problem is
> without having to grep/Google/look stuff up.

Be happy, that's the way the code is today ;)  I'm not sure what you'd have to 
look up though since a good app would be printing the output of apr_strerror in 
addition to the numeric error code, so the issue becomes whether something like

   (9)can't read from socket: an invalid file descriptor was specified

is acceptable when

   (20095)can't read from socket: an APR limitation on the range of file 
descriptors was encountered

is possible.  The latter is clearly not the insidious type of bug where one 
thread mucks with some other thread's file descriptors (perhaps due to double 
close), whereas the former allows several possible explanations.

(I have no plans to take action, since the only objection I've seen is an 
objection to my objection to the code I committed :) )