Wireshark · Ethereal-dev: Re: [Ethereal-dev] serious bug: g_snprintf also uses "UNIX style" 64 bit formatting even on Win32 sy

[Ulf Lamping <ulf.lamping@xxxxxx>]

Guy Harris wrote:

> Ulf Lamping wrote:
>  
>
> > Unfortunately, on Win32 the g_snprintf function don't use the Win32
> > functions, but using it's own implementation in glib\gnulib\vasnprintf.
> >    
>
> GLib 1.2[.x] uses the native "vsnprintf()" if present and the native
> "vsprintf()" (into a buffer whose size is set from
> "g_printf_string_upper_bound()") otherwise.
>
> Unfortunately, "g_printf_string_upper_bound()" does its *own*
> interpretation of the format string; it understands %q[douxX], %L[douxX],
> and %ll[douxX], but *NOT* %I64[douXx].
>
> 2.4.5, at least, uses the native print routines if available;
>  
That's wrong!

The Win32 build has native print routines available, but at least in the 
way it's currently compiled the functions form

glib\gnulib\vasnprintf are used. You probably mean #ifdef HAVE_GOOD_PRINTF as it's used in gprintfint.h.

> "g_printf_string_upper_bound()" uses "_g_vsnprintf()", under the
> assumption that it returns the number of characters it would have liked to
> have generated had it not been told that the buffer was only 1 character
> long.
>
>  
>
> > - replace *all* instances of printf like functions with the g_ functions
> > (my favourite)
> >    
>
> Will the g_ functions support %ll[douxX] on all platforms?  If not, would
> we have to do configure-script checks to see what works with them?
>  
Hmmm, we have to do something against it, it will currently crash (at 
least the Win32 build) at several places :-(

Do we need another set of PRId64 alike macros for use in the GLib 
functions? Something like PRId64g?

Regards, ULFL