Complete.Org: Mailing Lists: Archives: freeciv-dev: March 2003:
[Freeciv-Dev] Re: (PR#3579) When stdarg.h should be included?
Home

[Freeciv-Dev] Re: (PR#3579) When stdarg.h should be included?

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: nightmare@xxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#3579) When stdarg.h should be included?
From: "Raimar Falke" <rf13@xxxxxxxxxxxxxxxxx>
Date: Sun, 2 Mar 2003 08:24:08 -0800
Reply-to: rt@xxxxxxxxxxxxxx

On Sun, Mar 02, 2003 at 04:20:12AM -0800, Davide Pagnin wrote:
> 
>       Hi all!
> 
> I've fallen into this question, just some days ago, because of a build
> problem on my alpha Tru64 5.1B Platform.
> 
> (I have installed gcc 3.2.2 and cause of a partially wrong installation,
> freeciv doesn't compile, issuing strange errors caused by va_list)
> 
> After resolving issues of the gcc 3.2.2 installation on my alpha
> machine, the problem has been solved, and now freeciv compile cleanly,
> but I'm not satisfied anyway with actual situation of headers inclusion
> on freeciv.
> 
> There are 2 problems:
> 
> 1) Coding style state that an alphabetical order should be used, but
> this is not followed in many if all, the relevant files.
> 
> 2) The subject question still applies.
> 
> AFAIK, stdarg.h is part of ANSI C standard, and should be included when
> variable argument lists relevant macros are used.
> 
> There is a relevant exception to this rule, in the event that you
> include stdio.h, it is not needed that you include stdarg.h, because
> some POSIX standard, require that va_list macros are defined also in
> that file.
> 
>  I think that we should state something on this, to prevent confusion
> and perhaps, errors, in some broken system or on systems not fully
> compliant to ANSI or POSIX standards.
> 
> All in all, it is acceptable to be one of this 2 solution:
> 
> 1) Removing stdarg.h from all files where stdio.h is included and
> va_list are used and also remove it from all files where va_list are not
> used.
> 
> 2) Including stdarg.h in all files where va_list are used, and remove it
> from files that don't use va_list.
> 
> I personally vote for solution 2, because this choice plays friendly
> with not fully ANSI compliants OS headers.
> 
> End of this analysis, this is a list of relevent files:
> 
> There are, then, plenty of file that include stdarg.h and don't use
> va_list (this is plain wrong, IMHO)
> 
> There are also some file that don't include stdarg.h and use va_list (as
> some other that do include it, this "confusion" is also wrong, IMHO)
> client/climisc.c
> client/gui-gtk-2.0/gui_main.c
> common/shared.c
> server/plrhand.c
> 
> In particular, che case of server/plrhand.c is critical, because it does
> not include stdio.h either, and va_list are included only cause "log.h"
> is included (which includes stdarg.h), and expect that something used
> directly by the file (va_list) is included by a not expected do to so
> include file, is clearly wrong, IMHO.

> If there are no objection, I will produce a patch that will implement
> solution 2.

I agree.

Add the include to
./client/climisc.c
./client/gui-gtk-2.0/gui_main.c
./server/plrhand.c

./common/shared.c gets it from shared.h

Remove the extra includes from:
./client/gui-gtk/cityrep.c
./client/gui-gtk/inteldlg.c
./client/gui-gtk-2.0/cityrep.c
./client/gui-gtk-2.0/inteldlg.c
./client/gui-mui/citydlg.c
./client/gui-mui/cityrep.c
./client/gui-mui/dialogs.c
./client/gui-mui/inteldlg.c
./client/gui-win32/cityrep.c
./client/gui-win32/inteldlg.c
./client/gui-win32/messagedlg.c
./client/gui-win32/ratesdlg.c
./client/gui-xaw/cityrep.c
./client/gui-xaw/inteldlg.c
./client/gui-xaw/messagedlg.c
./client/gui-xaw/optiondlg.c
./client/gui-xaw/ratesdlg.c
./client/gui-xaw/repodlgs.c
./client/gui-sdl/cityrep.c
./client/gui-sdl/inteldlg.c

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "The very concept of PNP is a lovely dream that simply does not translate to
  reality. The confusion of manually doing stuff is nothing compared to the
  confusion of computers trying to do stuff and getting it wrong, which they
  gleefully do with great enthusiasm." 
    -- Jinx Tigr in the SDM




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