<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: http://gcc.gnu.org/c99status.html)? 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 Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
