This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [PATCH v4 0/5] fix wrong program abort on __FD_ELT
- From: KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>, libc-alpha <libc-alpha at sourceware dot org>, "libc-ports at sourceware dot org" <libc-ports at sourceware dot org>
- Date: Wed, 01 May 2013 18:21:31 -0400
- Subject: Re: [PATCH v4 0/5] fix wrong program abort on __FD_ELT
- References: <1365900451-19026-1-git-send-email-kosaki dot motohiro at gmail dot com> <51808721 dot 5090507 at redhat dot com> <CAHGf_=poxrBNzcZHBtSjZ3D2uj9bF1FoFqj_yVgd7Va4eDmHEw at mail dot gmail dot com> <518128DE dot 1070908 at redhat dot com>
>> @comment sys/types.h
>> @comment BSD
>> @deftypevr Macro int FD_SETSIZE
>> The value of this macro is the maximum number of file descriptors that a
>> @code{fd_set} object can hold information about. On systems with a
>> fixed maximum number, @code{FD_SETSIZE} is at least that number. On
>> some systems, including GNU, there is no absolute limit on the number of
>> descriptors open, but this macro still has a constant value which
>> controls the number of bits in an @code{fd_set}; if you get a file
>> descriptor with a value as high as @code{FD_SETSIZE}, you cannot put
>> that descriptor into an @code{fd_set}.
>> @end deftypevr
>>
>
> This should be expanded to say that at least on Linux you can allocate
> space from the heap and describe which macros are safe to use in that
> case (and what you need to do to avoid asserts from _FORTIFY_SOURCE).
Hmm...
ok, I try to wording.