public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
From: "Carlos O'Donell" <carlos@redhat.com>
To: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Cc: libc-alpha <libc-alpha@sourceware.org>,
	       "libc-ports@sourceware.org" <libc-ports@sourceware.org>
Subject: Re: [PATCH v4 0/5] fix wrong program abort on __FD_ELT
Date: Wed, 01 May 2013 14:38:00 -0000	[thread overview]
Message-ID: <518128DE.1070908@redhat.com> (raw)
In-Reply-To: <CAHGf_=poxrBNzcZHBtSjZ3D2uj9bF1FoFqj_yVgd7Va4eDmHEw@mail.gmail.com>

On 05/01/2013 01:31 AM, KOSAKI Motohiro wrote:
> On Tue, Apr 30, 2013 at 11:08 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>> On 04/13/2013 08:47 PM, KOSAKI Motohiro wrote:
>>> Changes from v3 to v4
>>>  - remove _STRICT_FD_SIZE_CHECK ifdef.
>>>  - instead, always check buffersize. requested from Florian Weimer.
>>
>> Do we want to update manual/llio.texi to describe those macros
>> that can work with heap allocated fd sets?
>>
>> These macros are being clearly used in Linux and BSD to operate
>> on heap allocated sets, and the glibc versions of some of these
>> macros do support those uses.
> 
> The manual already explains this case. I guess GNU/Hurd also support
> the same extension.
> 
> 
> @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).

Cheers,
Carlos.

  reply	other threads:[~2013-05-01 14:38 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-14  0:47 KOSAKI Motohiro
2013-04-14  0:47 ` [PATCH 1/5] __fdelt_chk: Removed range check KOSAKI Motohiro
2013-05-01  2:25   ` Carlos O'Donell
2013-05-01  6:40     ` KOSAKI Motohiro
2013-05-01 14:45       ` Carlos O'Donell
2013-05-01 22:13         ` KOSAKI Motohiro
2013-05-03  2:52           ` Carlos O'Donell
2013-04-14  0:47 ` [PATCH 4/5] tst-chk1: add fd_set dynamic allocation test KOSAKI Motohiro
2013-05-01  2:44   ` Carlos O'Donell
2013-05-01  6:29     ` KOSAKI Motohiro
2013-04-14  0:47 ` [PATCH 2/5] __FD_ELT: Implement correct buffer overflow check KOSAKI Motohiro
2013-05-01  2:42   ` Carlos O'Donell
2013-05-01  6:28     ` KOSAKI Motohiro
2013-05-01 14:42       ` Carlos O'Donell
2013-05-01 20:32         ` KOSAKI Motohiro
2013-05-03  3:15           ` Carlos O'Donell
2013-05-01 20:11       ` KOSAKI Motohiro
2013-05-03  3:15         ` Carlos O'Donell
2013-04-14  0:47 ` [PATCH 5/5] __FDS_BITS: Added cast to __fd_mask* to avoid warning KOSAKI Motohiro
2013-05-01  2:44   ` Carlos O'Donell
2013-04-14  0:47 ` [PATCH 3/5] update libc.abilist KOSAKI Motohiro
2013-05-01  3:08 ` [PATCH v4 0/5] fix wrong program abort on __FD_ELT Carlos O'Donell
2013-05-01  5:31   ` KOSAKI Motohiro
2013-05-01 14:38     ` Carlos O'Donell [this message]
2013-05-01 22:21       ` KOSAKI Motohiro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=518128DE.1070908@redhat.com \
    --to=carlos@redhat.com \
    --cc=kosaki.motohiro@gmail.com \
    --cc=libc-alpha@sourceware.org \
    --cc=libc-ports@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).