bug-gnulib
[Top][All Lists]
Advanced

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

Re: next m4 snapshot [was: M4 1.4.14 on AIX 7.1BETA]


From: Eric Blake
Subject: Re: next m4 snapshot [was: M4 1.4.14 on AIX 7.1BETA]
Date: Fri, 30 Jul 2010 15:03:48 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Lightning/1.0b2pre Mnenhy/0.8.3 Thunderbird/3.1.1

On 07/30/2010 09:58 AM, Rainer Tammer wrote:
> Not quite... but it's getting better...
> 
> Test "0xg" case is fixed.

Thanks for the positive feedback - we're getting closer.

> 
> # ./test-strtod
> test-strtod.c:435: assertion failed
>   {
>     const char input[] = "0xp";
>     char *ptr;
>     double result;
>     errno = 0;
>     result = strtod (input, &ptr);
>     ASSERT (result == 0.0);
>     ASSERT (!signbit (result));
>     ASSERT (ptr == input + 1);  <-  fail
>     ASSERT (errno == 0);
>   }
> (dbx) print ptr
> ""
> (dbx) print *ptr
> '\0'
> (dbx) print input
> "0xp"

Ouch.  That's a new one - no other system has had that particular bug.
There has to be digits between the x and p for it to be a valid floating
hex constant.  And since it is returning input+3, it bypasses our checks
for end <= input + 2.

I'll work up another fix ;)

The others in between are signs of the same problem.

> test-strtod.c:762: assertion failed
>   {
>     const char input[] = "0x1p";
>     char *ptr;
>     double result;
>     errno = 0;
>     result = strtod (input, &ptr);
>     ASSERT (result == 1.0); 
>     ASSERT (ptr == input + 3);  <- fail
>     ASSERT (errno == 0);
>   }

And yet another problem, but I'm guessing here as I don't have your
debugger output.  I'm guessing it parsed "0x1p" instead of "0x1" - the p
must not be parsed if there is no exponent.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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