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

This transaction appears to have no content
Hello,

Please let me take a step back from the patch that I sent before.  I have
attached smaller one to this email.  I will explain in detail what it does.

Essentially, the patch just allows freeciv 2.1.8 to be compiled with the sun
studio 11/08 compiler.  There seem to be some differences in C99 compliance
between sun studio and gcc.  The file client/gui-gtk-2.0/repodlgs.c contains
defines the size of an array called upkeep in terms of O_COUNT.  I may be
incorrect, but O_COUNT seems to be field of an enumeration.  The sun studio
compiler considers this to be variable and will therefore not allow it be
used as the size of a variable array, while gcc considers it fixed and
therefore does.  The change to that file simply uses and integer for the
size.  The error message which comes out of the sun studio compiler with the
unpatched file is:

source='repodlgs.c' object='repodlgs.o' libtool=no \
    depfile='/repodlgs.Po' tmpdepfile='/repodlgs.TPo' \
    depmode=none /bin/sh ../../bootstrap/depcomp \
    /opt/sun/sunstudioceres/bin/cc -DHAVE_CONFIG_H -I. -I. -I../..  -I.
-I./.. -I./../include -I../../utility -I../../common -I../../common/aicore
-I../../intl -I./../agents -I/usr/include/gtk-2.0
-I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1
-I/usr/include/freetype2 -I/usr/include/libpng12
-DLOCALEDIR="\"/home/jmcclain/freeciv/share/locale\""
-DDEFAULT_DATA_PATH="\".:data:~/.freeciv:/home/jmcclain/freeciv/share/freeciv\""
-O3 -native -xchar=signed -c `test -f 'repodlgs.c' || echo './'`repodlgs.c
"../../common/packets_gen.h", line 929: member can not have variably
modified type: upkeep
"repodlgs.c", line 1204: cannot dereference non-pointer type
"repodlgs.c", line 1228: cannot dereference non-pointer type
"repodlgs.c", line 1229: cannot dereference non-pointer type
"repodlgs.c", line 1230: cannot dereference non-pointer type
"repodlgs.c", line 1243: cannot dereference non-pointer type
"repodlgs.c", line 1243: cannot dereference non-pointer type
"repodlgs.c", line 1254: cannot dereference non-pointer type
"repodlgs.c", line 1255: cannot dereference non-pointer type
"repodlgs.c", line 1256: cannot dereference non-pointer type
cc: acomp failed for repodlgs.c

All of those lines about not being able to dereference non-pointer types are
lines on which arrays called "upkeep" are used -- the compiler seems to have
been confused by the earlier and unrelated declaration of an array called
upkeep (which is fixed by the attached patch).

The change to client/helpdata.c is because of another peculiarity in this
particular compiler.  For the "? : " construct, the compiler expects the
things on both sides of the ":" to be of the same type (another issue of
strictness).  Because the thing on the right of the colon is a macro which
is explicity cast to void and the thing on the left has type int, there is a
mis-match.  My patch simply explicity casts the thing on the left to type
void.

As as regards the #if 's: I understand that those are not acceptable for
inclusion.  Those are there in the event that you or others wanted to apply
the patch then condition the changes on some macro defined by the
configuration system.

Sorry for not explaining more fully before.

Sincerely,
James McClain

On Wed, Dec 31, 2008 at 7:08 PM, Madeline Book <madeline.b...@gmail.com>wrote:

>
> <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.
>
>
> -----------------------------------------------------------------------
> 競技に参加するつもりですか?
>



-- 
(From Memory Alpha) Doctor Richard Daystrom was one of the most influential
human scientists of the 23rd Century. Daystrom who was born ca. 2219, was
considered a genius in his day, and was compared to such minds as Albert
Einstein, Kazanga and Sitar of Vulcan.
Hello,

Please let me take a step back from the patch that I sent before.  I have attached smaller one to this email.  I will explain in detail what it does.

Essentially, the patch just allows freeciv 2.1.8 to be compiled with the sun studio 11/08 compiler.  There seem to be some differences in C99 compliance between sun studio and gcc.  The file client/gui-gtk-2.0/repodlgs.c contains defines the size of an array called upkeep in terms of O_COUNT.  I may be incorrect, but O_COUNT seems to be field of an enumeration.  The sun studio compiler considers this to be variable and will therefore not allow it be used as the size of a variable array, while gcc considers it fixed and therefore does.  The change to that file simply uses and integer for the size.  The error message which comes out of the sun studio compiler with the unpatched file is:

source='repodlgs.c' object='repodlgs.o' libtool=no \
    depfile='/repodlgs.Po' tmpdepfile='/repodlgs.TPo' \
    depmode=none /bin/sh ../../bootstrap/depcomp \
    /opt/sun/sunstudioceres/bin/cc -DHAVE_CONFIG_H -I. -I. -I../..  -I. -I./.. -I./../include -I../../utility -I../../common -I../../common/aicore -I../../intl -I./../agents -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12    -DLOCALEDIR="\"/home/jmcclain/freeciv/share/locale\"" -DDEFAULT_DATA_PATH="\".:data:~/.freeciv:/home/jmcclain/freeciv/share/freeciv\""  -O3 -native -xchar=signed -c `test -f 'repodlgs.c' || echo './'`repodlgs.c
"../../common/packets_gen.h", line 929: member can not have variably modified type: upkeep
"repodlgs.c", line 1204: cannot dereference non-pointer type
"repodlgs.c", line 1228: cannot dereference non-pointer type
"repodlgs.c", line 1229: cannot dereference non-pointer type
"repodlgs.c", line 1230: cannot dereference non-pointer type
"repodlgs.c", line 1243: cannot dereference non-pointer type
"repodlgs.c", line 1243: cannot dereference non-pointer type
"repodlgs.c", line 1254: cannot dereference non-pointer type
"repodlgs.c", line 1255: cannot dereference non-pointer type
"repodlgs.c", line 1256: cannot dereference non-pointer type
cc: acomp failed for repodlgs.c

All of those lines about not being able to dereference non-pointer types are lines on which arrays called "upkeep" are used -- the compiler seems to have been confused by the earlier and unrelated declaration of an array called upkeep (which is fixed by the attached patch).

The change to client/helpdata.c is because of another peculiarity in this particular compiler.  For the "? : " construct, the compiler expects the things on both sides of the ":" to be of the same type (another issue of strictness).  Because the thing on the right of the colon is a macro which is explicity cast to void and the thing on the left has type int, there is a mis-match.  My patch simply explicity casts the thing on the left to type void.

As as regards the #if 's: I understand that those are not acceptable for inclusion.  Those are there in the event that you or others wanted to apply the patch then condition the changes on some macro defined by the configuration system.

Sorry for not explaining more fully before.

Sincerely,
James McClain

On Wed, Dec 31, 2008 at 7:08 PM, Madeline Book <madeline.b...@gmail.com> wrote:

<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.


-----------------------------------------------------------------------
競技に参加するつもりですか?



--
(From Memory Alpha) Doctor Richard Daystrom was one of the most influential human scientists of the 23rd Century. Daystrom who was born ca. 2219, was considered a genius in his day, and was compared to such minds as Albert Einstein, Kazanga and Sitar of Vulcan.
diff -ru freeciv-2.1.8/client/gui-gtk-2.0/repodlgs.c /home/jmcclain/src/freeciv-2.1.8/client/gui-gtk-2.0/repodlgs.c
--- freeciv-2.1.8/client/gui-gtk-2.0/repodlgs.c	2008-11-30 12:53:30.000000000 +0000
+++ /home/jmcclain/src/freeciv-2.1.8/client/gui-gtk-2.0/repodlgs.c	2008-12-31 19:15:09.000000000 +0000
@@ -1178,7 +1178,11 @@
 {
   struct repoinfo {
     int active_count;
+#if 0
     int upkeep[O_COUNT];
+#else
+    int upkeep[0x10];
+#endif
     int building_count;
   };
 
diff -ru freeciv-2.1.8/client/helpdata.c /home/jmcclain/src/freeciv-2.1.8/client/helpdata.c
--- freeciv-2.1.8/client/helpdata.c	2008-11-30 12:54:04.000000000 +0000
+++ /home/jmcclain/src/freeciv-2.1.8/client/helpdata.c	2008-12-31 01:29:53.000000000 +0000
@@ -239,7 +239,7 @@
   /* FIXME: show other data like range and survives. */
 #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)))
 
 
_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Reply via email to