From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10829 invoked by alias); 9 Mar 2010 19:15:18 -0000 Received: (qmail 10774 invoked by uid 22791); 9 Mar 2010 19:15:17 -0000 X-Spam-Check-By: sourceware.org Received: from pool-96-252-118-25.bstnma.fios.verizon.net (HELO cgf.cx) (96.252.118.25) by sourceware.org (qpsmtpd/0.83/v0.83-20-g38e4449) with ESMTP; Tue, 09 Mar 2010 19:15:13 +0000 Received: from ednor.cgf.cx (ednor.casa.cgf.cx [192.168.187.5]) by cgf.cx (Postfix) with ESMTP id 3A73713C0C8; Tue, 9 Mar 2010 14:15:12 -0500 (EST) Received: by ednor.cgf.cx (Postfix, from userid 201) id 3714A2B352; Tue, 9 Mar 2010 14:15:12 -0500 (EST) Date: Tue, 09 Mar 2010 19:15:00 -0000 From: Christopher Faylor To: gdb-patches@sourceware.org, Pierre Muller Subject: Re: [RFA] Fix remote-fileio.c compilation for Cygwin 1.5 API Message-ID: <20100309191512.GB2977@ednor.casa.cgf.cx> Mail-Followup-To: gdb-patches@sourceware.org, Pierre Muller References: <000901cabeda$3cd7bd00$b6873700$@muller@ics-cnrs.unistra.fr> <20100308200858.GA28304@caradoc.them.org> <20100308214856.GA18247@ednor.casa.cgf.cx> <000f01cabf16$07402330$15c06990$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000f01cabf16$07402330$15c06990$@muller@ics-cnrs.unistra.fr> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-03/txt/msg00368.txt.bz2 On Tue, Mar 09, 2010 at 12:21:05AM +0100, Pierre Muller wrote: >> >> I do not really know if there is a specific maintainer for this >> >> file... Could someone (a global maintainr?) >> >> please review this patch? >> > >> >This is OK. >> >> Sorry, I guess I was wrong about the opinion. I do have a mild one. >> >> While I said I didn't have an opinion about this, wouldn't it really >> make sense to use the same mechanism that I adopted for windows-nat.c? > >The problem is that this macro does not check the value of the first >argument, which makes me fear that if someone reuses >cygwin_conv_path function elsewhere inside remote-fileio.c source >we might get into the same troubles as the ones >I just discovered for windows-nat.c > >See http://sourceware.org/ml/gdb-patches/2010-03/msg00344.html You're right. My macro was too simple minded. I've checked in your change to windows-nat.c. If you want to use that in remote-fileio.c that's fine. Or not. It really isn't a big deal either way. cgf