From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29603 invoked by alias); 8 Oct 2007 14:31:13 -0000 Received: (qmail 29589 invoked by uid 22791); 8 Oct 2007 14:31:08 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO brahms.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 08 Oct 2007 14:31:04 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.1/8.14.0) with ESMTP id l98EUXsr001495; Mon, 8 Oct 2007 16:30:33 +0200 (CEST) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.1/8.14.1/Submit) id l98EUXqG000789; Mon, 8 Oct 2007 16:30:33 +0200 (CEST) Date: Mon, 08 Oct 2007 14:31:00 -0000 Message-Id: <200710081429.l98ETtZD002804@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: muller@ics.u-strasbg.fr CC: brobecker@adacore.com, gdb-patches@sourceware.org In-reply-to: <000001c809b5$4c51a9d0$e4f4fd70$@u-strasbg.fr> (muller@ics.u-strasbg.fr) Subject: Re: [RFA] ARI fix: Replace dirent.h by gdb_dirent.h in linux-fork.c References: <009d01c809a7$a52fc9a0$ef8f5ce0$@u-strasbg.fr> <200710081326.l98DQs62013226@brahms.sibelius.xs4all.nl> <009f01c809b1$f15c5280$d414f780$@u-strasbg.fr> <20071008135843.GL3570@adacore.com> <000001c809b5$4c51a9d0$e4f4fd70$@u-strasbg.fr> 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: 2007-10/txt/msg00154.txt.bz2 > From: "Pierre Muller" > Date: Mon, 8 Oct 2007 16:12:45 +0200 > > The include ordering stuff seems completely > opaque to me anyhow. > is included as last in linux-fork.c, > but right after "defs.h" in breakpoint.c. > Is there any rational for this? Other than that people have been sloppy in the past? No I don't think so. > Anyhow, if you also agree, it is probably best to leave > the ordering exactly as it was, just to stay on the > safe side. > > Should I move the gdb_wait.h include back to where wait.h was? I'd prefer that; consider a patch that does that pre-approved.