From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9884 invoked by alias); 1 May 2013 14:38:26 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 9834 invoked by uid 89); 1 May 2013 14:38:25 -0000 X-Spam-SWARE-Status: No, score=-7.2 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 X-Spam-User: qpsmtpd, 2 recipients Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 01 May 2013 14:38:25 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r41EcNeH022021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 May 2013 10:38:23 -0400 Received: from [10.3.113.84] (ovpn-113-84.phx2.redhat.com [10.3.113.84]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r41EcM6t008246; Wed, 1 May 2013 10:38:22 -0400 Message-ID: <518128DE.1070908@redhat.com> Date: Wed, 01 May 2013 14:38:00 -0000 From: "Carlos O'Donell" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: KOSAKI Motohiro CC: libc-alpha , "libc-ports@sourceware.org" Subject: Re: [PATCH v4 0/5] fix wrong program abort on __FD_ELT References: <1365900451-19026-1-git-send-email-kosaki.motohiro@gmail.com> <51808721.5090507@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-05/txt/msg00011.txt.bz2 On 05/01/2013 01:31 AM, KOSAKI Motohiro wrote: > On Tue, Apr 30, 2013 at 11:08 PM, Carlos O'Donell 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.