bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: test-vsprintf-posix: make check failure


From: Eric Blake
Subject: Re: test-vsprintf-posix: make check failure
Date: Mon, 22 Sep 2008 17:56:17 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

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







reply via email to

[Prev in Thread] Current Thread [Next in Thread]