On 10/25/13 14:38, Otto Moerbeek wrote:
> On Fri, Oct 25, 2013 at 02:31:47PM +0200, Giovanni Bechis wrote:
>
>> On Fri, Oct 25, 2013 at 01:31:45PM +0200, J?r?mie Courr?ges-Anglas wrote:
>>>
>>> Hi,
>>>
>>> I don't think this happened before the time_t bump, I'm not sure whether
>>> it happens only on 32 bits archs (I only have this at hand), but nmap is
>>> unusable for me. It fails on an assert call before printing any result.
>>>
>>> Now, looking at the code, there's something fishy involving struct
>>> timeval, doubles and weird fp arithmetic. No idea why that code doesn't
>>> use only struct timeval, but anyway...
>>>
>>> I've launched nmap with debug fprintfs, and the difference between the
>>> two double values is always so small in the failing case that I like to
>>> think about a fp math error more than about a real, logic error.
>>>
>>> Can you reproduce the failing assert on 64 bits archs? If so, would the
>>> diff below be ok?
>>>
>> This assert is 32bit only, this diff will fix the problem.
>
> to me this diff looks wrong, you can't just change the vars to
> integral types and have double constants being used all over the
> place.
>
> It might circumvent the assert, but the timing class is made to handle
> doubles.
>
I am aware of it nmap need a lot more patching, all classes using double for
time values should be changed, this is just a partial diff^Whack to let nmap
start on i386.
Cheers
Giovanni
