From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7867 invoked by alias); 13 Apr 2007 09:07:26 -0000 Received: (qmail 7678 invoked by uid 22791); 13 Apr 2007 09:07:24 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 13 Apr 2007 10:07:21 +0100 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 5698048CE3F for ; Fri, 13 Apr 2007 05:07:19 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 04111-01-3 for ; Fri, 13 Apr 2007 05:07:19 -0400 (EDT) Received: from joel.gnat.com (dhcp-guest.act-europe.fr [212.157.227.127]) by nile.gnat.com (Postfix) with ESMTP id 0914848CE1E for ; Fri, 13 Apr 2007 05:07:19 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id B26C3E7B4C; Fri, 13 Apr 2007 11:09:08 +0200 (CEST) Date: Fri, 13 Apr 2007 09:07:00 -0000 From: Joel Brobecker To: gdb@sourceware.org Subject: Re: [mingw32] stdin redirection Message-ID: <20070413090908.GC3488@adacore.com> References: <20070411144451.GA21140@caradoc.them.org> <20070411145104.GE58502@adacore.com> <20070411151234.GA22185@caradoc.them.org> <20070412145818.GG3886@adacore.com> <20070412151221.GA856@caradoc.them.org> <20070412155253.GH3886@adacore.com> <20070412160356.GA15004@caradoc.them.org> <20070412163113.GK3886@adacore.com> <20070412182338.GA30608@caradoc.them.org> <20070412185644.GA1271@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070412185644.GA1271@caradoc.them.org> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-04/txt/msg00088.txt.bz2 > Mark Mitchell pointed out the same thing that Dave did - > WaitForMultipleObjects is documented to take various things. One of > them is an event handle. None of them are pipe handles nor file > handles. What we're doing now for pipes is within the bounds of the > MS documentation; passing it directly to select is not and I think it > would be unwise. Windows is confusing enough when you use it as > documented. I'm understanding better and better how this is supposed to work in GDB as well as what the Windows API provides, and I agree with you on all counts. > If you want to add a third case that handles files, maybe by checking > if they are seekable and if so that the position is not at the end, > I'd be more OK with that. You could return a signalled event handle > if there are bytes and an unsignalled one if there are not. Let's try to do that. If the check you suggest allows us to differentiate between pipes and files without corrupting pipe handles, then the rest should be pretty easy... Thanks a lot for everyone's help! -- Joel