On Fri, Oct 25, 2013 at 03:34:21PM +0200, Giovanni Bechis wrote:
> 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
Wat values are represented by these doubles? To me it looks they hold
fractional values.
-Otto
