[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Consolidating EOL functions to libsvn_subr/eol.c. (3rd try)

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 19 Aug 2009 08:35:02 +0100

On Wed, 2009-08-19 at 09:02 +0800, Edmund Wong wrote:
> Stefan Sperling wrote:
[...]
> >> +#include "svn_io.h"
> >> +
> >> +#include "svn_private_config.h"
> >> +#include "private/svn_eol_private.h"
> >
> > It should still be possible to trim more headers.
> > Maybe start with no header at all, and then add just the necessary
> > headers to make it compile, one-by-one?
>
> Thanks. I've done that but there is an item that I don't quite
> understand. Since this is eol.c, should I not have
> #include "private/svn_eol_private.h" in the header? Should it
> (being the compiler) complain of a missing header if I were
> to leave it out?
>
> I've whittled the headers down to two major ones and the
> #include "private/svn_eol_private.h" one, but if I were to
> take it out, the program still compiles. Does that mean
> it isn't necessary to have his include line?

A C file should always include the header that declares the functions it
is defining. Doing so enables the compiler to check that the prototypes
match the definitions. (To reinforce this practice, a compiler can warn
if it sees a public (non-static) function for which it has not seen a
prototype. For GCC, Subversion's Makefile uses the -Wmissing-prototypes
option to do this.)

The general rule for other headers is that you include a header if it is
responsible for providing anything that you directly use. For example,
if you use svn_string_t then you should include <svn_string.h>, even if
you are already including another header that happens to include
<svn_string.h> for its own purposes.

- Julian

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2385123
Received on 2009-08-19 09:35:45 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.