From: Pedro Alves <palves@redhat.com>
To: Doug Evans <dje@google.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Always include defs.h first.
Date: Thu, 08 Nov 2012 16:49:00 -0000 [thread overview]
Message-ID: <509BE290.4000104@redhat.com> (raw)
In-Reply-To: <CADPb22QMBu5e5Vrxzm6aehYNnD2cBbiacb_STeZPKa7i-rpGiQ@mail.gmail.com>
On 11/08/2012 01:34 AM, Doug Evans wrote:
> On Wed, Nov 7, 2012 at 12:11 PM, Pedro Alves <palves@redhat.com> wrote:
>> defs.h should always be the first included header in a .c file. In
>> turn, this means that a foo.h header should not need to include
>> defs.h, as the .c file always includes defs.h before including foo.h.
>
> fwiw, I like the idea of header files including what they themselves
> need, and not assuming the includer will do it for them, even for
> defs.h.
> It's something I'd like to see gdb move towards, but I'm not in a hurry. :-)
Sorry, I hadn't imagined the change could be disagreeable. Otherwise, I'd
have waited.
I'm also of the camp that advocates that header files should include what
they themselves need. OTOH, IMO, defs.h is special.
- It's defs.h that includes config.h. Including config.h in headers
is bad practice. Comparing to gcc, I'd say defs.h is currently a
kind of a mix of system.h and coretypes.h, and whatnot.
- It's needed practically _everywhere_.
Also:
$ ls gdb/*.h | wc -l
232
since not including defs.h in headers is the de facto standard on the code
base, where only 4 of those 232 had "#include defs.h" in them, and another
include was being introduced exactly because the corresponding .c file was in
error, I thought it best to just get rid of those 4 instances making the
codebase a little bit less inconsistent.
--
Pedro Alves
next prev parent reply other threads:[~2012-11-08 16:49 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-07 20:11 Pedro Alves
2012-11-08 1:34 ` Doug Evans
2012-11-08 16:49 ` Pedro Alves [this message]
2012-11-08 18:12 ` Doug Evans
2012-11-08 18:39 ` Joel Brobecker
2012-11-08 18:50 ` Pedro Alves
2012-11-08 18:55 ` Pedro Alves
2012-11-08 19:00 ` Doug Evans
2012-11-08 19:15 ` Joel Brobecker
2012-11-08 19:21 ` Tom Tromey
2012-11-08 3:49 ` Yao Qi
2012-11-08 5:04 ` Joel Brobecker
2012-11-08 16:56 ` Pedro Alves
2012-11-09 8:12 ` Yao Qi
2012-11-08 17:04 ` Pierre Muller
2012-11-08 17:16 ` Pedro Alves
2012-11-08 19:37 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=509BE290.4000104@redhat.com \
--to=palves@redhat.com \
--cc=dje@google.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox