Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@redhat.com>
Cc: Andrew Cagney <ac131313@redhat.com>, gdb@sources.redhat.com
Subject: Re: Headers including other headers?
Date: Sat, 23 Feb 2002 09:56:00 -0000	[thread overview]
Message-ID: <3C77D7D5.3040502@cygnus.com> (raw)
In-Reply-To: <20020223172336.372F05E9DE@zwingli.cygnus.com>

The style guide says:

http://sources.redhat.com/gdb/onlinedocs/gdbint_13.html#SEC111

> All `.c' files should include `defs.h' first.
> 
> All `.c' files should explicitly include the headers for any declarations they refer to. They should not rely on files being included indirectly.
> 
> With the exception of the global definitions supplied by `defs.h', a header file should explictily include the header declaring any typedefs et.al. it refers to.
> 
> extern declarations should never appear in .c files.
> 
> All include files should be wrapped in:
> 
>  
> 
> #ifndef INCLUDE_FILE_NAME_H
> #define INCLUDE_FILE_NAME_H
> header body
> #endif

along with:

http://sources.redhat.com/gdb/onlinedocs/gdbint_13.html#SEC107

> Declarations like `struct foo *' should be used in preference to declarations like `typedef struct foo { ... } *foo_ptr'.



(Daniel J, note clause #1 :-).

> Suppose a header file in gdb/ contains code cannot be compiled without
> definitions from other header files --- it uses typedefs, structures
> in a way that requires their size, etc.  Is it more proper for the
> header file to #include the other headers it requires itself, or
> should it be the responsibility of the .c file #including it to also
> bring in its prerequisites?
> In hopes that this doesn't start a really long thread of unsatisfying
> disagreements: I personally think that this is not a matter of huge
> consequence either way, but it's nicer to have a consistent pattern,
> so having someone simply establish any reasonable guideline is more
> important than the actual details of that guideline.
> 
> I'm not volunteering to convert our existing headers; I just want to
> know what style is recommended for new header files.

If you find you need to #include a system header file (since defs.h 
doesn't include it) then consider re-structuring the code so that GDB 
uses a host independant type - make the object opaque for instance.

Andrew


      reply	other threads:[~2002-02-23 17:56 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-23  9:23 Jim Blandy
2002-02-23  9:56 ` Andrew Cagney [this message]

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=3C77D7D5.3040502@cygnus.com \
    --to=ac131313@cygnus.com \
    --cc=ac131313@redhat.com \
    --cc=gdb@sources.redhat.com \
    --cc=jimb@redhat.com \
    /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