<URL: http://bugs.freeciv.org/Ticket/Display.html?id=40616 >

> [james.mccl...@gmail.com - Wed Dec 31 01:55:26 2008]:
> This email contains a patch that allows version 2.1.8 of
> FreeCiv to compile under the 11/08 version (the latest
> I believe) version of the Sun Studio Community Edition
> compiler. The patch seems to produce working executables
> on the AMD64 version of OpenSUSE 11.1 with the compiler
> mentioned above.  The changes are all minor ones which
> have to do with differences in implementation of the C99
> standard between the Sun Studio compiler and gcc.

I don't understand the purpose of the changes in your patch;
what are the errors returned by the compiler for the existing
code? And where can I find a c99 implementation status page
for the "sun studio compiler" (for example, like the gcc one:

The main c99 feature in use in the freeciv code is variable
length arrays (i.e. arrays allocated on the stack); most
other c99 uses can be rephrased to equivalent c expressions,
I would hope.

Also I don't agree with the way your patch changes the code.
If anything the #if should be on the compiler version, and
not "#if 0" or "#if 1". The way upkeep_ptr is used is very
unattractive. Why does it have to be a global variable, why
not just declare it in the scope of the function? Why does
it have to be a pointer anyway?

Is it the 'struct repoinfo' definition within the function
activeunits_report_dialog_update() that is causing the
compiler to choke? Why not just move it out then? Since
there are plently of uses of

struct foo { int array[A_CONSTANT]; };

elsewhere in the code. Maybe it is the type of 'O_COUNT'
that is messing it up? So make it a macro or just use
O_LAST. (Where do you even get 0x20 from?)

I find it hard to believe that your compiler would accept

> upkeep_ptr = &(unitarray[unit_type(punit)->index].upkeep);
> *(upkeep_ptr + o) += punit->upkeep[o];

but not

> unitarray[unit_type(punit)->index].upkeep[o] += punit->upkeep[o];

What part of either expression is specific to c99? I would
guess that this kind of code occurs in numerous other places
as well, yet it only causes compilation problems here? :(

>  #define COREQ_APPEND(s) \
>    (coreq_buf[0] != '\0' \
> -   ? cat_snprintf(coreq_buf, sizeof(coreq_buf), Q_("?clistmore:,
> %s"), (s))  \
> +   ? (void)cat_snprintf(coreq_buf, sizeof(coreq_buf),
> Q_("?clistmore:, %s"), (s)) \
>     : sz_strlcpy(coreq_buf, (s)))

This macro is hideous already, and should at least be made
into an inline function.


Freeciv-dev mailing list

Reply via email to