We're under a lock and this didn't go in yet. I think it should,
otherwise we'll ship totally broken nmap for i386 (and probably
other 32-bit archs).
There was a 6.40 update, too, but it's too late now.
Initial idea and further input from jca@.
okay?
--
zhuk@
Index: Makefile
===================================================================
RCS file: /cvs/ports/net/nmap/Makefile,v
retrieving revision 1.109
diff -u -p -r1.109 Makefile
--- Makefile 23 Jan 2014 00:40:57 -0000 1.109
+++ Makefile 10 Feb 2014 09:37:39 -0000
@@ -6,7 +6,7 @@ COMMENT-zenmap= graphical frontend for n
MODPY_EGG_VERSION= 6.25
DISTNAME= nmap-${MODPY_EGG_VERSION}
PKGNAME-main= ${DISTNAME}
-REVISION-main= 1
+REVISION-main= 2
PKGNAME-zenmap= nmap-zenmap-${MODPY_EGG_VERSION}
CATEGORIES= net security
Index: patches/patch-timing_cc
===================================================================
RCS file: patches/patch-timing_cc
diff -N patches/patch-timing_cc
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-timing_cc 10 Feb 2014 09:37:39 -0000
@@ -0,0 +1,22 @@
+$OpenBSD$
+Unbreak run-time operation on i386 at least.
+--- timing.cc.orig Sat Apr 7 12:07:38 2012
++++ timing.cc Mon Feb 10 13:32:41 2014
+@@ -95,6 +95,8 @@
+
+ /* $Id: timing.cc 28413 2012-04-07 08:07:38Z david $ */
+
++#include <limits>
++
+ #include "timing.h"
+ #include "NmapOps.h"
+ #include "utils.h"
+@@ -405,7 +407,7 @@ void RateMeter::update(double amount, const struct tim
+ interval = MAX(current_rate_history, diff);
+ else
+ interval = TIMEVAL_SUBTRACT(*now, start_tv) / 1000000.0;
+- assert(diff <= interval);
++ assert(diff <= interval + std::numeric_limits<float>::epsilon());
+ /* If we record an amount in the very same instant that the timer is
started,
+ there's no way to calculate meaningful rates. Ignore it. */
+ if (interval == 0.0)
