From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KVPaM-00052i-Bp for qemu-devel@nongnu.org; Tue, 19 Aug 2008 07:41:14 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KVPaK-0004zV-3Y for qemu-devel@nongnu.org; Tue, 19 Aug 2008 07:41:13 -0400 Received: from [199.232.76.173] (port=41367 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KVPaJ-0004yx-Hq for qemu-devel@nongnu.org; Tue, 19 Aug 2008 07:41:11 -0400 Received: from wr-out-0506.google.com ([64.233.184.236]:14322) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KVPaJ-0002Cs-E4 for qemu-devel@nongnu.org; Tue, 19 Aug 2008 07:41:11 -0400 Received: by wr-out-0506.google.com with SMTP id c46so3637247wra.18 for ; Tue, 19 Aug 2008 04:41:10 -0700 (PDT) Date: Tue, 19 Aug 2008 13:40:29 +0200 From: Bernhard Reutner-Fischer Subject: Re: [Qemu-devel] pty/tty functions for BSD too Message-ID: <20080819114029.GD2484@mx.loc> References: <20080819103337.GB2484@mx.loc> <3170595319-BeMail@laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3170595319-BeMail@laptop> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Tue, Aug 19, 2008 at 01:21:27PM +0200, François Revol wrote: >> On Mon, Aug 18, 2008 at 09:08:50PM +0300, Blue Swirl wrote: >> >> >Glibc uses an internal PATH_MAX buffer. If the name does not fit, >> > the >> >buffer will be doubled in size: >> >http://sourceware.org/cgi-bin/cvsweb.cgi/libc/login/openpty.c?rev=1.8&content-type=text/x-cvsweb-markup&cvsroot=glibc >> > > > >> >But in practice the pty will be allocated using getpt(), which uses >> >> They, too, should switch to posix_openpt(), fwiw. > >Please don't start dictating what an OS should have or not, or this I'm not talking about an OS but a libc that should try to use standard conforming functions where possible. Whether or not they provide the non-standard getpt() for legacy applications is not the question. A libc that is POSIX.1-2001 compliant has to provide posix_openpt() anyway, thus it doesn't make too much sense to use the non-standard getpt() but i guess nobody cared enough to adjust glibc yet. >will turn into ffmpeg-like porting flames. >It's not about porting all OSes to QEMU, but porting QEMU to OSes :P Well, i talked about glibc interna, not QEMU interna, so my comment was a bit OT, admittedly ;)