From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27862 invoked by alias); 4 Feb 2006 15:35:29 -0000 Received: (qmail 27854 invoked by uid 22791); 4 Feb 2006 15:35:29 -0000 X-Spam-Check-By: sourceware.org Received: from gandalf.inter.net.il (HELO gandalf.inter.net.il) (192.114.186.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 04 Feb 2006 15:35:28 +0000 Received: from nitzan.inter.net.il (nitzan.inter.net.il [192.114.186.20]) by gandalf.inter.net.il (MOS 3.7.1-GA) with ESMTP id HTT09960; Sat, 4 Feb 2006 17:35:19 +0200 (IST) Received: from HOME-C4E4A596F7 (IGLD-84-228-244-26.inter.net.il [84.228.244.26]) by nitzan.inter.net.il (MOS 3.7.3-GA) with ESMTP id CPY85996 (AUTH halo1); Sat, 4 Feb 2006 17:35:18 +0200 (IST) Date: Sat, 04 Feb 2006 15:35:00 -0000 Message-Id: From: Eli Zaretskii To: Mark Kettenis CC: gdb-patches@sourceware.org, jimb@red-bean.com In-reply-to: <200602041532.k14FWpPo018123@elgar.sibelius.xs4all.nl> (message from Mark Kettenis on Sat, 4 Feb 2006 16:32:51 +0100 (CET)) Subject: Re: RFA: Support Windows extended error numbers in safe_strerror Reply-to: Eli Zaretskii References: <20060203215455.GA3501@nevyn.them.org> <200602032325.k13NPJ6g028001@elgar.sibelius.xs4all.nl> <8f2776cb0602031706s55e09abfr4354becf8278921c@mail.gmail.com> <20060204030025.GA9890@nevyn.them.org> <200602041532.k14FWpPo018123@elgar.sibelius.xs4all.nl> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00085.txt.bz2 > Date: Sat, 4 Feb 2006 16:32:51 +0100 (CET) > From: Mark Kettenis > CC: gdb-patches@sourceware.org, jimb@red-bean.com > > > #ifdef NEED_FOOBAR > > foobar (); > > #endif > > > > with the body of `foobar' hiding all the rest on a Windows-specific > > source file. I think such a method minimizes the bad impact of > > ifdef's and does not annoy too much when one reads the sources. > > This is slightly better, but starts to get problematic if there are > many places in the code where this is necessary. I think we can worry about that when we come to that point. For now, I'll be happy just to reach consensus on using this method ;-)