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 743936 - glib: handle unsigned modifier for long long in internal printf
glib: handle unsigned modifier for long long in internal printf
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
unspecified
Other Linux
: Normal minor
: ---
Assigned To: gtkdev
gtkdev
: 693347 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-02-03 15:03 UTC by Aurélien Zanelli
Modified: 2017-11-16 11:00 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
glib: handle unsigned modifier for long long in internal printf (950 bytes, patch)
2015-02-03 15:04 UTC, Aurélien Zanelli
committed Details | Review

Description Aurélien Zanelli 2015-02-03 15:03:11 UTC
When internal printf is used, ie HAVE_GOOD_PRINTF not defined, and when HAVE_LONG_LONG_FORMAT is not defined, print_long_long function is used to display both unsigned and signed long long type.

However, this function doesn't handle 'u' modifier, so it display an unsigned long long as a signed one which is not the expected behavior.

For instance a test program like:
int main(...)
{
  guint64 tmp = G_MAXUINT64;
  g_print ("G_MAXUINT64=%" G_GUINT64_FORMAT "\n", tmp);
  return 0;
}

displays G_MAXUINT64=-1
Comment 1 Aurélien Zanelli 2015-02-03 15:04:06 UTC
Created attachment 296026 [details] [review]
glib: handle unsigned modifier for long long in internal printf

Proposal patch to handle 'u' modifier
Comment 2 Colin Walters 2015-02-03 16:47:27 UTC
Does this affect upstream gnulib too?  Hmm...it looks like glib's copy of vasnprintf was last synchronized in 2003.  The gnulib code is pretty radically different today.

Honestly, I think the best thing is for you to get a copy of glibc and avoid using glib's included printf code...it's obviously undermaintained.
Comment 3 Colin Walters 2015-02-03 16:50:17 UTC
Review of attachment 296026 [details] [review]:

Change looks fine to me.
Comment 5 Aurélien Zanelli 2015-02-03 18:08:52 UTC
(In reply to comment #2)
> Does this affect upstream gnulib too?  Hmm...it looks like glib's copy of
> vasnprintf was last synchronized in 2003.  The gnulib code is pretty radically
> different today.
I try to check in upstream, but as you said, code is different, so I don't really know if it's affect or not upstream because I think code to handle long long was added in glibc.

> 
> Honestly, I think the best thing is for you to get a copy of glibc and avoid
> using glib's included printf code...it's obviously undermaintained.

After some other investigations, I succeeded to make glib use system printf instead of included one by forcing some autoconf variables: ac_cv_func_vsnprintf_c99, ac_cv_func_printf_unix98 and glib_cv_long_long_format
and it seems to work too :)

So I may have a problem with features detection, but first, I will try to figure out what my libc really supports or not.
If interested, or just for records, I use eglibc-2.15
Comment 6 Colin Walters 2015-02-03 18:20:05 UTC
I'd use OpenEmbedded as a reference point here:

https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-core/glib-2.0/glib.inc#L36
Comment 7 Philip Withnall 2017-11-16 10:59:57 UTC
Comment on attachment 296026 [details] [review]
glib: handle unsigned modifier for long long in internal printf

(Was pushed as 5b74681f5b4dd3f5fc93b82a4f706c2337d76a8d.)
Comment 8 Philip Withnall 2017-11-16 11:00:24 UTC
*** Bug 693347 has been marked as a duplicate of this bug. ***