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 670548 - Missing return value in gst-libs/gst/tag/gstxmptag.c
Missing return value in gst-libs/gst/tag/gstxmptag.c
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.x
Other Linux
: Normal normal
: 0.10.37
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-02-21 15:44 UTC by Vincent Untz
Modified: 2012-03-05 10:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
tag: xmp: Fix a build warning (1.03 KB, patch)
2012-02-21 15:45 UTC, Vincent Untz
committed Details | Review

Description Vincent Untz 2012-02-21 15:44:54 UTC
gstxmptag.c: In function 'xmp_tag_type_get_name':
gstxmptag.c:178:1: warning: control reaches end of non-void function [-Wreturn-type]

It turns out this make the build fail for the openSUSE package.
Comment 1 Vincent Untz 2012-02-21 15:45:37 UTC
Created attachment 208147 [details] [review]
tag: xmp: Fix a build warning

Return a value even if the code will never be reached, to make compilers
happy.
Comment 2 Tim-Philipp Müller 2012-02-21 16:11:07 UTC
Why not, but I'm fairly sure there will be more of those, because we use G_DISABLE_ASSERT for releases.

I think it's something in your package builder that makes it fail though, not on our side, for releases warnings should not be fatal.

I've just replaced the assert with a g_return_val_if_fail() now, so we don't get compiler warnings about unreachable code when we compile without asserts disabled later.

 commit 5c3f7b51ce31fdcc31a2d8ef0d3154a40c1e927d
 Author: Vincent Untz <vuntz@gnome.org>
 Date:   Tue Feb 21 16:43:59 2012 +0100

    tag: xmp: Fix a build warning when compiling with asserts disabled
    
    Return a value even if the code will never be reached, to make compilers
    happy.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=670548
Comment 3 Vincent Untz 2012-02-21 16:37:37 UTC
(In reply to comment #2)
> I think it's something in your package builder that makes it fail though, not
> on our side, for releases warnings should not be fatal.

Oh, yes, we have some tools that look at the build logs and that look for gcc warnings; and for some warnings (like this one), the tools decide that the code is too wrong to be accepted.
Comment 4 Stefan Sauer (gstreamer, gtkdoc dev) 2012-03-05 09:59:32 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > I think it's something in your package builder that makes it fail though, not
> > on our side, for releases warnings should not be fatal.
> 
> Oh, yes, we have some tools that look at the build logs and that look for gcc
> warnings; and for some warnings (like this one), the tools decide that the code
> is too wrong to be accepted.

Is that visible publicly?
Comment 5 Vincent Untz 2012-03-05 10:20:00 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > I think it's something in your package builder that makes it fail though, not
> > > on our side, for releases warnings should not be fatal.
> > 
> > Oh, yes, we have some tools that look at the build logs and that look for gcc
> > warnings; and for some warnings (like this one), the tools decide that the code
> > is too wrong to be accepted.
> 
> Is that visible publicly?

The output is visible in the OBS build logs. And I guess the tool is https://gitorious.org/opensuse/post-build-checks/blobs/master/checks-data/check_gcc_output