Simon Josefsson <simon <at> josefsson.org> writes:
>
> FYI, this fails on a vanilla debian x86 testing system:
>
> gnulib-tool --with-tests --test vsprintf-posix
>
> Here is the debug backlog:
>
I'm seeing it too; it comes from an attempt to call vasnprintf("%Ld", 0.0L).
It stems from the fact that this particular choice of glibc skips the #ifdef at
line 2070, because %a handling is provided natively:
#if (NEED_PRINTF_DIRECTIVE_A || NEED_PRINTF_LONG_DOUBLE || NEED_PRINTF_DOUBLE)
&& !defined IN_LIBINTL
but then takes the test at line 2561 which supplies inf/-0.0 handling, since
glibc doesn't recognize pseudo-NaNs on x86:
#if (NEED_PRINTF_INFINITE_DOUBLE || NEED_PRINTF_DOUBLE ||
NEED_PRINTF_INFINITE_LONG_DOUBLE || NEED_PRINTF_LONG_DOUBLE) && !defined
IN_LIBINTL
else if ((dp->conversion == 'f' || dp->conversion == 'F'
|| dp->conversion == 'e' || dp->conversion == 'E'
|| dp->conversion == 'g' || dp->conversion == 'G'
|| dp->conversion == 'a' || dp->conversion == 'A')
Unfortunately, vasnprintf was not prepared for this, and line 3143 only handles
f, e, and g when printing [-]0.0. It looks like the solution is to also add
support at line 3149 (for long double) for the %a format (this is asymmetric
from line 3619 for double, although so far, we haven't encountered a platform
that supports %A but where infinite/NaN doubles aren't properly recognized).
--
Eric Blake
