After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 731425 - giomodule protects function-call with different token than function's implementation
giomodule protects function-call with different token than function's impleme...
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gio
2.38.x
Other Mac OS
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2014-06-09 19:14 UTC by Daniel Macks
Modified: 2014-06-10 13:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Sync giomodule.c g_nextstep_settings_backend_get_type protection (1.10 KB, patch)
2014-06-09 19:26 UTC, Daniel Macks
committed Details | Review

Description Daniel Macks 2014-06-09 19:14:20 UTC
giomodule.c around line 1063:

#ifdef HAVE_CARBON
      g_nextstep_settings_backend_get_type ();
#endif

The g_nextstep_settings_backend_get_type function is prototyped in gsettingsbackendinternal.h around line 90:

#ifdef HAVE_COCOA
GType                   g_nextstep_settings_backend_get_type            (void);
#endif

and the compiling of its implementation (gnextstepsettingsbackend.c) is controlled by Makefile.am around line 132:

if OS_COCOA
settings_sources += \
	gnextstepsettingsbackend.c
endif

The function-call should be protected by testing the same token as controls the availability of the function. The implementation itself does appear to be cocoa-based, so it seems that it's giomodule.c that is the one that is incorrect.
Comment 1 Daniel Macks 2014-06-09 19:26:27 UTC
Created attachment 278161 [details] [review]
Sync giomodule.c g_nextstep_settings_backend_get_type protection