Complete.Org: Mailing Lists: Archives: freeciv-dev: October 2002:
[Freeciv-Dev] Re: Compiler Warnings When Compiling GTK Client For OpenVM
Home

[Freeciv-Dev] Re: Compiler Warnings When Compiling GTK Client For OpenVM

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Robert Alan Byer <byer@xxxxxxxxxxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Compiler Warnings When Compiling GTK Client For OpenVMS...
From: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Date: Wed, 16 Oct 2002 22:20:08 +0200

On Tue, Oct 15, 2002 at 01:24:16PM -0500, Robert Alan Byer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> 
> In my ever on going quest to get OpenVMS support updated in FreeCiv, I 
> encounted the following compiler warnings while compiling 
> ../freeciv-1.14/client/gtk-client
> 
> All are pointer mismatches and everything seems to work fine, but thought I 
> should bring it up in case anyone wanted to clean up the code a little.

>     icon_bitmap = gdk_bitmap_create_from_data(root_window, cityicon_bits,
> ...........................................................^
> %CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer 
> value "
> cityicon_bits" is "unsigned char", which is not compatible with "const char".
> at line number 1447 in file DISK$WORK:[TEST.FREECIV-1_14.CLIENT.GUI-GTK]

Davide noticed this before for the Xaw client and added "(char *)" at
the various *_bits variables. Looks like this is also needed for the
GTK client. The alternative is that someone brings me a reference that
XBMs are using signed char and I will change all the XBMs.

> CITYDLG.C;1
> %LIBRAR-W-COMCOD, compilation warnings in module CITYDLG file 
> DISK$WORK:[TEST.FR
> EECIV-1_14.CLIENT.GUI-GTK]CITYDLG-AXP.OBJ;1
>         SYS$DISK:[-.CLIENT.GUI-GTK]CITYREP.C
> 
>   TestCityFunc test_func = gtk_object_get_data(parent, "freeciv_test_func");
> ...........................^
> %CC-W-PTRMISMATCH, In the initializer for test_func, the referenced type of 
> the 
> pointer value "gtk_object_get_data(...)" is "void", which is not compatible 
> with
>  "function (pointer to struct city, int) returning int".
> at line number 254 in file 
> DISK$WORK:[TEST.FREECIV-1_14.CLIENT.GUI-GTK]CITYREP.C
> ;1

While this is correct there is AFAIK an implicit casting rule so that
"void *" is implicitly casted to any other pointer. This was removed
in C++ and this is the reason why we have casts like
./common/sbuffer.c:121:  sb = (struct sbuffer *)fc_malloc(sizeof(*sb));
in the code.

>   gtk_object_set_data(GTK_OBJECT(submenu), "freeciv_test_func", test_func);
> ................................................................^
> %CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer 
> value "
> test_func" is "function (pointer to struct city, int) returning int", which 
> is not compatible with "void".
> at line number 348 in file 
> DISK$WORK:[TEST.FREECIV-1_14.CLIENT.GUI-GTK]CITYREP.C
> ;1

This is the other way around. Not sure about this one.

>     buttons[i].callback = va_arg(args, void *);
> ....^
> %CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer 
> value "
> (args=(__va_list)((char ...)args+(((__IS_X_FLOAT_BUILTIN(void 
> ...)?sizeof(long d
> ouble ...):sizeof(void ...))+7)&~7)),__IS_X_FLOAT_BUILTIN(void ...)?(**(
> void ...)((char ...)arg
> s-(((__IS_X_FLOAT_BUILTIN(void ...)?sizeof(long double ...):sizeof(void ..." 
> is 
> "void", which is not compatible with "function (pointer to void) returning 
> void".
> at line number 1604 in file 
> DISK$WORK:[TEST.FREECIV-1_14.CLIENT.GUI-GTK]DIALOGS.
> C;1

Yes "void *" should to be replaced with
  typedef void (*callback_type) (gpointer);
  buttons[i].callback = va_arg(args, callback_type);

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Programming today is a race between software engineers striving to
  build bigger and better idiot-proof programs, and the Universe trying
  to produce bigger and better idiots. So far, the Universe is winning."
    -- Rich Cook


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