From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20165 invoked by alias); 17 Jan 2020 07:57:22 -0000 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 Received: (qmail 20157 invoked by uid 89); 17 Jan 2020 07:57:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 17 Jan 2020 07:57:11 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43705) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1isMVB-0007Fx-Hi; Fri, 17 Jan 2020 02:57:09 -0500 Received: from [176.228.60.248] (port=4872 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1isMVA-0001M2-Br; Fri, 17 Jan 2020 02:57:09 -0500 Date: Fri, 17 Jan 2020 08:48:00 -0000 Message-Id: <83d0bi348d.fsf@gnu.org> From: Eli Zaretskii To: Christian Biesinger CC: palves@redhat.com, tromey@adacore.com, gdb-patches@sourceware.org In-reply-to: (message from Christian Biesinger on Thu, 16 Jan 2020 15:46:52 -0500) Subject: Re: [PATCH 2/3] Consistently use BFD's time References: <20200114210956.25115-1-tromey@adacore.com> <20200114210956.25115-3-tromey@adacore.com> <83wo9s4sac.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg00503.txt.bz2 > From: Christian Biesinger > Date: Thu, 16 Jan 2020 15:46:52 -0500 > Cc: Eli Zaretskii , Tom Tromey , > gdb-patches > > > - #undef stat before including bfd headers. > > - Redefine it afterwards back to rpl_stat (*) > > - add some kind of wrapper around bfd_stat (like maybe called gdb_bfd_stat) > > Wouldn't it be easier to #define GNULIB_NAMESPACE in this file? That > way, the gnulib stuff stays in gnulib:: (or gdb::, or whatever), and > the global ::stat is the system one. That would work, of course, but is there a chance we store some fields of 'struct stat' in other data structures or objects, and then use them elsewhere, for example for comparison with values received from the Gnulib's 'stat' or 'fstat'? And in any case, we will have to have a prominent commentary explaining why we do such strange things. I wonder whether a better way is not to import the Gnulib 'stat' and 'fstat' modules at all. Are they required by other Gnulib modules, and if so, by which ones? Thanks.