Re: [PATCH] long long for printf on MinGW

[Andrew STUBBS <andrew dot stubbs at st dot com>]

Daniel Jacobowitz wrote:
> However, for host types we could import the printf (vsprintf-posix)
> module from gnulib, then always assume PRINTF_HAS_LONG_LONG as long as
> HAVE_LONG_LONG_INT.  I did the work of adding gnulib modules already.
> So maybe this is a better option.  What do you think?

I'm not sufficiently familiar with gnulib to know what gotchas there 
might be, but I imagine it would at least solve the problem of different 
behaviour on different hosts, given the same target.

That said, selfishly speaking, it's overkill for _my_ problem, and I 
don't know of any other problems in this area - apart from hosts that 
just plain don't have long long, and you seem to suggest that gnulib 
won't solve that?

> > +	      /* Windows' printf does support long long, but not the usual way.
> > +		 Convert %lld to %I64d.  */
> > +	      int length_before_ll = f - last_arg - 1 - lcount;
> > +	      strncpy (current_substring, last_arg, length_before_ll);
> > +	      strcpy (current_substring + length_before_ll, "I64");
> > +	      current_substring[length_before_ll + 3] =
> > +		last_arg[length_before_ll + lcount];
> > +	      current_substring += length_before_ll + 4;
>
> You've got enough buffer space to do this but I had to think about it
> a couple times to work out why :-)

Unless I'm mistaken, the code reserves enough space for every character 
to be in it's own nul-terminated substring, but since the minimum length 
%-spec is two characters, that's impossible. In this specific example, 
there would be 8 bytes reserved for the string "%lld" - enough for 
"%\0l\0l\0d\0", but "%I64d\0" only uses 6.