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 699008 - Fix printf format compiler warning
Fix printf format compiler warning
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-omx
git master
Other Linux
: Normal normal
: 1.2.0
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-04-27 00:58 UTC by Carlos Rafael Giani
Modified: 2014-07-23 08:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
printf call patch (892 bytes, patch)
2013-04-27 00:59 UTC, Carlos Rafael Giani
committed Details | Review

Description Carlos Rafael Giani 2013-04-27 00:58:58 UTC
gst-omx git fails to compile on platforms where size_t and OMX_U32 are not the same type (because of a printf call which is using %zu in its format string). Explicit casting to size_t solves the problem.
Comment 1 Carlos Rafael Giani 2013-04-27 00:59:57 UTC
Created attachment 242632 [details] [review]
printf call patch
Comment 2 Tim-Philipp Müller 2013-04-27 08:19:33 UTC
Thanks!

 commit 2d1138f45cb482fcf0e2aba5ec40bd4c1cdb5853
 Author: Carlos Rafael Giani <dv@pseudoterminal.org>
 Date:   Sat Apr 27 02:50:25 2013 +0200

    omx: fixed type error in printf call
    
    %zu expects size_t
    
    https://bugzilla.gnome.org/show_bug.cgi?id=699008

I bet those %zu (instead of "%" G_GSIZE_FORMAT) in other places will cause problems as well, since gsize is not necessarily typedef'ed to size_t but might be something else of equivalent size on the specific platform, which might then confuse the compiler, sigh.
Comment 3 Sebastian Dröge (slomo) 2013-04-29 06:42:29 UTC
Where do these %zu come from at all? I didn't even know it existed :)

IMHO we should use G_GSIZE_FORMAT and friends, and cast all these weird OMX types to proper types as necessary.
Comment 4 Tim-Philipp Müller 2013-04-29 08:05:30 UTC
> Where do these %zu come from at all? I didn't even know it existed :)

My fault that. It's C99, which we couldn't use so far because we couldn't rely on the printf implementation supporting it in all cases, but now with the new implementation we could, I thought.
 
> IMHO we should use G_GSIZE_FORMAT and friends, and cast all these weird OMX
> types to proper types as necessary.

Yes, probably. I started using %zu there before thinking about the gsize typedef thing and whether the compiler will complain about that or not. I think we should just leave it in for now and see if it causes any problems.
Comment 5 Sebastian Dröge (slomo) 2013-05-03 09:25:49 UTC
Let's reopen this then
Comment 6 Tim-Philipp Müller 2013-08-20 14:13:33 UTC
Ok, so just for the record: gcc will actually warn in some cases even if the size of the type is the same on the system as the type size_t, meaning we can't use the 'z' modifier. (I wasn't sure if it would only warn if the size actually differs, in which case we'd been okay because glib will typedef the right thing).

Tested on x86: sizeof(): int=4,long=4,size=4,int64=8
gst/gst.c:72:3: error: format ‘%zd’ expects argument of type ‘signed size_t’, but argument 8 has type ‘glong’:
   GST_ERROR ("size=%zd", v_long);
Comment 7 Tim-Philipp Müller 2013-08-20 15:01:27 UTC
commit 498b74ab6a779570cdcc2300d732a387dfe07dcf
Author: Tim-Philipp Müller <tim@centricular.net>
Date:   Tue Aug 20 16:00:07 2013 +0100

    omx: don't use the 'z' modifier to print size_t
    
    gcc will warn in some cases even if the size of the type
    is exactly that of size_t on the platform.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=699008