2016-08-23 4:45 GMT+09:00 Danek Duvall <duv...@comfychair.org>: > I'm seeing these warnings when building on Solaris with the Studio > compilers. > > "gui_gtk_f.c", line 507: warning: argument #6 is incompatible with > prototype: > prototype: pointer to void : > "/usr/include/glib-2.0/gobject/gsignal.h", > line 431 > argument : pointer to function(void) returning void > "gui_gtk_f.c", line 510: warning: argument #6 is incompatible with > prototype: > prototype: pointer to void : > "/usr/include/glib-2.0/gobject/gsignal.h", > line 431 > argument : pointer to function(void) returning void > "gui_gtk_f.c", line 795: warning: argument #6 is incompatible with > prototype: > prototype: pointer to void : > "/usr/include/glib-2.0/gobject/gsignal.h", > line 431 > argument : pointer to function(void) returning void > "gui_gtk_f.c", line 797: warning: argument #6 is incompatible with > prototype: > prototype: pointer to void : > "/usr/include/glib-2.0/gobject/gsignal.h", > line 431 > argument : pointer to function(void) returning void > "gui_beval.c", line 522: warning: argument #6 is incompatible with > prototype: > prototype: pointer to void : > "/usr/include/glib-2.0/gobject/gsignal.h", > line 431 > argument : pointer to function(void) returning void > "gui_beval.c", line 536: warning: argument #6 is incompatible with > prototype: > prototype: pointer to void : > "/usr/include/glib-2.0/gobject/gsignal.h", > line 431 > argument : pointer to function(void) returning void > > Frankly, it seems like it's a gtk/glib mismatch, since all the mechanism > comes from those headers: GTK_SIGNAL_FUNC is G_CALLBACK, which just casts > its argument to GCallback, which is the function pointer mentioned above, > while the function prototype for gtk_signal_disconnect_by_func() takes a > gpointer, which is the void *. >
Hi Danek, I think that mismatch is not our fault, either. It looks strange that gtk/glib relies on an implicit conversion from a pointer to function types to the generic pointer of object types, which is not necessarily guaranteed to work on every platform. That said, it would take some time to file the issue against them and wait for their response to that; it would be better for us to do something about that for ourselves. So I made a patch for fixing the issue, which is attached to this mail. For that, I assumed that the Solaris Studio had the predefined constant macro __SUNPRO_C. Is that assumption OK? If that's OK, could you try the patch to check if it works as expected? Note that the patch includes some minor fixes on coding style, too. > glib is 2.46, gtk3 is 3.18. > > I don't see this in the travis logs, but I can't tell from there what > versions of glib and gtk are in use. > > Does this look familiar to anyone? > I didn't see either clang or gcc (generic one, not the one which is a symbolic link to clang) giving me any warning on the mismatch. I didn't know about that until I read you report. Best regards, Kazunobu > > Thanks, > Danek > > -- > -- > You received this message from the "vim_dev" maillist. > Do not top-post! Type your reply below the text you are replying to. > For more information, visit http://www.vim.org/maillist.php > > --- > You received this message because you are subscribed to the Google Groups > "vim_dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to vim_dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
solaris-studio-gtk3-warnings.patch
Description: Binary data
