On Sun, Feb 16, 2020 at 02:22:45PM -0500, James McCoy wrote:
> Interestingly, changing
>
> vim_snprintf((char *)p, IOSIZE - (p - IObuff),
> NGETTEXT("%lld character", "%lld characters", nchars),
> (long_long_T)nchars);
>
> to
>
> vim_snprintf((char *)p, IOSIZE - (p - IObuff),
> NGETTEXT("%ld foo %lld character", "%ld foo %lld characters",
> nchars), 42L,
> (long_long_T)nchars);
>
> "fixes" the problem.
>
> The extra format spec (which mimics the L/C status) seems to have a
> relevant effect here.
Yeah, that changes the va_list so the value is properly aligned to be
read via a 32-bit value. If the value were more than 32-bits, then the
reporting would also be wrong (either way) because without FEAT_NUM64
defined, Vim internally turns the %lld into %ld.
This is the root of the problem. It's unconditionally doing this
transformation when built without FEAT_NUM64, which controls whether
vimscript supports 64-bit variables, even though vim_snprintf() isn't
being used solely for formatting vim variables.
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
