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 571153 - [pulsemixer] compiler warnings (on ARM)
[pulsemixer] compiler warnings (on ARM)
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal blocker
: 0.10.15
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 557565 571164 573110 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-02-10 10:41 UTC by Mark Nauwelaerts
Modified: 2009-02-25 14:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix build. (1.73 KB, patch)
2009-02-10 10:43 UTC, Mark Nauwelaerts
committed Details | Review

Description Mark Nauwelaerts 2009-02-10 10:41:53 UTC
gst-plugins-good/ext/pulse/pulsemixerctrl.c: In function 'gst_pulsemixer_ctrl_sink_info_cb':
gst-plugins-good/ext/pulse/pulsemixerctrl.c:96: warning: passing argument 1 of 'g_atomic_int_get' from incompatible pointer type
gst-plugins-good/ext/pulse/pulsemixerctrl.c:99: warning: passing argument 1 of 'g_atomic_int_set' from incompatible pointer type
<etc etc>
Comment 1 Mark Nauwelaerts 2009-02-10 10:43:12 UTC
Created attachment 128364 [details] [review]
Fix build.

* More casting, less warnings.
Comment 2 Sebastian Dröge (slomo) 2009-02-10 10:54:59 UTC
*** Bug 557565 has been marked as a duplicate of this bug. ***
Comment 3 Jan Schmidt 2009-02-10 11:12:08 UTC
not sure if this is actually allowed: an enum should be convertible to/from an int type, but may not actually be stored that way (compiler dependent)... even though it usually is.

On the other hand, if it's not valid to cast the enum pointer to gint *, the only other fix is to add a mutex - yech.
Comment 4 Sebastian Dröge (slomo) 2009-02-10 12:07:56 UTC
*** Bug 571164 has been marked as a duplicate of this bug. ***
Comment 5 Bastien Nocera 2009-02-10 12:11:21 UTC
Also affects PPC, as mentioned in the dupe.
Comment 6 Jan Schmidt 2009-02-13 17:41:59 UTC
Discussion on IRC seems to indicate that even though it's technically wrong, in practice it'll work fine.

In 0.11, we should use a guint32 in the mixer structure to store the flags (there's already a FIXME to this effect)
Comment 7 Mark Nauwelaerts 2009-02-13 17:54:53 UTC
commit 5cfc906d1be06ef1af58c909dd56f6f4cbd9af09
Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk>
Date:   Tue Feb 10 11:25:49 2009 +0100

    pulsemixer: Fix compiler warnings.

    Cast (enum *) to (int *), not necessarily technically right,
    but plugs #571153.
Comment 8 Sebastian Dröge (slomo) 2009-02-22 12:12:44 UTC
This introduced new warnings on amd64:

cc1: warnings being treated as errors
pulsemixerctrl.c: In function ‘gst_pulsemixer_ctrl_sink_info_cb’:
pulsemixerctrl.c:96: error: dereferencing type-punned pointer will break strict-aliasing rules
pulsemixerctrl.c:99: error: dereferencing type-punned pointer will break strict-aliasing rules
pulsemixerctrl.c: In function ‘gst_pulsemixer_ctrl_source_info_cb’:
pulsemixerctrl.c:145: error: dereferencing type-punned pointer will break strict-aliasing rules
pulsemixerctrl.c:148: error: dereferencing type-punned pointer will break strict-aliasing rules
pulsemixerctrl.c: In function ‘gst_pulsemixer_ctrl_set_mute’:
pulsemixerctrl.c:575: error: dereferencing type-punned pointer will break strict-aliasing rules
pulsemixerctrl.c:578: error: dereferencing type-punned pointer will break strict-aliasing rules
Comment 9 Sebastian Dröge (slomo) 2009-02-22 17:26:56 UTC
commit dfa627da30dd44e170f3249ff3bdda333ea1edf1
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Sun Feb 22 18:08:59 2009 +0100

    pulsemixer: Don't use g_atomic_int_(get|set) for accessing the mixer track f
    
    g_atomic_int_(get|set) only work on ints and the flags are
    an enum (which on most architectures is stored as an int).
    
    Also the way the flags were accessed atomically would still
    leave a possible race condition and we don't do it in any
    other mixer track implementation, let alone at any other
    place where an integer could be changed from different
    threads. Removing the g_atomic_int_(get|set) will only
    introduce a new race condition on architectures where
    integers could be half-written while reading them
    which shouldn't be the case for any modern architecture
    and if we really care about this we need to use
    g_atomic_int_(get|set) at many other places too.
    
    Apart from that g_atomic_int_(set|get) will result in
    aliasing warnings if their argument is explicitely
    casted to an int *. Fixes bug #571153.
Comment 10 Jan Schmidt 2009-02-25 14:14:47 UTC
*** Bug 573110 has been marked as a duplicate of this bug. ***