GNOME Bugzilla – Bug 661401
gmmproc: _WRAP_METHOD() allow commas in return type
Last modified: 2011-10-19 17:09:13 UTC
Created attachment 198733 [details] [review] Patch to allow commas in _WRAP_METHOD()'s return types Presently, if there is a comma in a _WRAP_METHOD()'s return type, gmmproc crashes because it splits the _WRAP_METHOD arguments incorrectly due to the comma in the return type. (A comma in a return is possible with, e.g. Glib::Variant< std::map<K, V> >). This patch fixes that so that C functions that return a variant dictionary type can be wrapped without gmmproc errors.
Sure. Go for it. Thanks.
Pushed to master.
I had to revert this commit because it is causing problems like this in libgdamm: make[1]: Entering directory `/home/murrayc/checkouts/gnome30/libgdamm/libgda/src' /usr/bin/perl -I"/opt/gnome30/lib/glibmm-2.4/proc/pm" -- "/opt/gnome30/lib/glibmm-2.4/proc/gmmproc" -I ../../tools/m4 --defs . batch . ../libgdamm m4:/tmp/gtkmmproc_30479.g1:111: ERROR: end of file in argument list
Sorry, since the second commit related to this didn't affect glibmm, I thought that it was okay. I'll try to find a better solution and post it here to make sure that it's okay.
Created attachment 199394 [details] [review] Patch to remove the gmmproc warnings due to commas in types This patch uses an alternative method to ensure there are no warnings from the __HASH2 macro generated due to commas in any of the two given types. Instead of quoting, it transliterates the commas to a character (namely 'C') that wont make the pushdef() calls think that one type is more than one argument which is what will happen to the types after the pushdef() calls anyway. I'm pretty sure the build will not break in any module because of this patch. However, be aware that I found warnings being generated with this patch for libgdamm because of a conversion in its convert_libgdamm.m4 file in line 90: _CONVERSION(`const int*','const-gint*',`$3') It seems the quoting is amiss in the second argument.
(In reply to comment #5) > _CONVERSION(`const int*','const-gint*',`$3') It could also be that this was causing problems because of the quoting change introduced in the reverted commit in which case it may be more desirable to use the reverted commit, I don't know.
The original commit: http://git.gnome.org/browse/glibmm/commit/?id=570314de2e0ff7635847695ec546d501817fb878 The commit that reverts it: http://git.gnome.org/browse/glibmm/commit/?id=d224aa28c9dc395c436f95bffc4a557a57ad0315
Created attachment 199395 [details] [review] Alternate patch to remove warnings ensuring that the transliteration does not take place if the types are missing Actually, there should be no reason why warnings should appear if some parameters are missing. This patch removes the warnings. The build for libgdamm would crash, however, and it would not be easy to see why. I don't see any way to prevent the warnings or crashes in libgdamm if gmmproc should deal with types that may have commas in them as the description of this bug describes. The previous patch is not obsolete because either one could be used to fix this bug.
(In reply to comment #5) > _CONVERSION(`const int*','const-gint*',`$3') > > It seems the quoting is amiss in the second argument. Fixed. Thanks for tracking that down.
If libgdamm builds for you, then please push the change again. Thanks.
It does build. Pushed the original commit with the adapted documentation of the macros in the new patches.