Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2004:
[Freeciv-Dev] Re: (PR#8547) GCC poisoning v2
Home

[Freeciv-Dev] Re: (PR#8547) GCC poisoning v2

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients: ;
Subject: [Freeciv-Dev] Re: (PR#8547) GCC poisoning v2
From: "Per I. Mathisen" <per@xxxxxxxxxxx>
Date: Tue, 20 Apr 2004 10:47:54 -0700
Reply-to: rt@xxxxxxxxxxx

<URL: http://rt.freeciv.org/Ticket/Display.html?id=8547 >

On Tue, 20 Apr 2004, Raimar Falke wrote:
> > What is bad: Moves stuff around without a clear idea of why some stuff
> > should be here and some there (shared.h vs support.h).
>
> What is the reason for the bool change and the various unistd.h?

support.c has the forbidden functions, and must have them. So it cannot
link in shared.h, yet it needs bool and the format macro - hence moving
them over. shared.c can link in support.h without problems.

The various new includes: We have to be careful that we don't include
system headers _after_ shared.h, or else the gcc poisoning will choke on
these functions in the system headers. This becomes a problem because some
freeciv header files include system headers (headers including headers is
generally a terribly bad idea, but there you go), so we need to preempt
these system headers included in freeciv headers by including them
in the .c file first. The include guard ensures that we don't include them
twice.

So where freeciv.c is

        #include "shared.h"
        #include "freeciv.h"

and where freeciv.h contains

        #include <system.h>

they will fail, since the system header comes last. Whereas where
freeciv.c is

        #include <system.h>
        #include "shared.h"
        #include "freeciv.h"

it will work fine, since by including the system header first in the .c
file, the include guard ensures it is not included later.

  - Per




[Prev in Thread] Current Thread [Next in Thread]