Re: FD_SET and FORTIFY_SOURCE

["Carlos O'Donell" <carlos at redhat dot com>]

On 03/25/2013 01:24 PM, KOSAKI Motohiro wrote:
> (3/25/13 1:04 PM), Carlos O'Donell wrote:
>> On 03/24/2013 04:17 PM, KOSAKI Motohiro wrote:
>>> 1. only turn on __FD_ELT check when running on hurd.
>>> 2. only turn on __FD_ELT check when defined some specific macro. (e.g.
>>> likes darwin,
>>>     but disable by default)
>>> 2-2. make FORTIFY_SOURCE variant and check POSIX compliance if enabled.
>>> 3. provide select_large_fdset() likes solaris. (I strongly don't
>>> recommend. all application
>>>     need to modify and recompilation)
>>>
>>> What do you think?
>>
>> The value of __FD_SETSIZE is part of the ABI and can't be changed.
> 
> ??
> We never discuss to change __FD_SETSIZE. A lot of UNIX support >FD_SETSIZE,
> but didn't change FD_SETSIZE.

Thank you for the clarification, you want to change the macros to simply
avoid checking for the size and let the user manage it.

The same problem still applies. If you pass this set to another library
compiled with the old macros it will fail.

How do you avoid that breakage without recompiling all dependent 
applications?

Your change would be an API breakage?
 
>> Alternatively rewrite using poll/epoll.
> 
> As far as I know, all of moder scripting language expose select interface to scripting
> and poll has different semantics against select(2). That makes no sense.
> 
> One of the way is, to avoid to use FD_SET and other FD_* family likes perl.
> perf enforce users to make fd bitmap by themself (by using vec()).
> 
> http://perldoc.perl.org/functions/select.html
> 
> But, it is extream ugly and useless. I don't think this makes a lot of sense.

Given that FD_SET that checks for <= 1024 is already in use, you can't
change the interface without interoperability issues between libraries.

New macro?

Cheers,
Carlos.