GNOME Bugzilla – Bug 744281
printf: Add support for %I32
Last modified: 2015-03-12 13:55:07 UTC
Created attachment 296534 [details] [review]
libav seems to output some messages with %I32u which can't currently be printed by gstreamer printf
Thanks, but what is it that adds those format modifiers? And what GLib version/OS?
I'm not sure how glib version is relevant here? Libav decoder logs message with given modifier and gst_debug_message_get uses __gst_vasprintf to print it. Where does glib or OS get into that?
As for what does those modifiers - It's a decoder warning. but i don't remember which decoder exactly and I wasn't able to find it with grep, the printf flags are probably put together in code (in libav).
The reason I ask is that I was trying to figure out where that modifier comes from, since I couldn't see glib checking for it or setting it, so I was basically wondering if it was "wrong use" of some sorts or not (defined as not using standard modifiers or glib printf macros) Also, we might want to add more variants.
I see. So the modifier comes from warning from libav decoder (not sure which one, sorry). It seems to be common on Windows platforms
I don't remember now why I didn't put %I64u there as well.
Does this mean this patch is completely untested then? :)
Not sure what you mean. I tested it when I wrote it. I had a file that gave me decoder warning (from gst-libav) with %I32u in it. I didn't get any %I64u warnings so I didn't implement that :)
But I did test %I32u of course. The only thing is that I don't remember which file it was anymore :)
I pushed this without the flags=32, which I think you made up or extrapolated from flags=64 ? (Since it broke the test for me)
Author: Tim-Philipp Müller <email@example.com>
Date: Thu Mar 12 13:26:59 2015 +0000
tests: add some basic unit tests for our printf stuff
To test new %I32 support.
Author: Matej Knopp <firstname.lastname@example.org>
Date: Tue Feb 10 17:40:48 2015 +0100
printf: add support for %I32
Yeah, that sounds like something I might have done. Sorry. Looking at the code now the flags should have remained 0 of course.