Stuart Henderson <st...@openbsd.org> writes: > On 2014/01/28 11:34, Giovanni Bechis wrote: >> On 01/28/14 11:20, Stuart Henderson wrote: >> > On 2014/01/28 09:51, Giovanni Bechis wrote: >> >> Update to latest version, >> >> this diff fixes time_t issues with i386 and uses internal libpcap to get >> >> rid of some ugly patches. >> >> Next we should work to let it build with our libpcap but that's another >> >> story. >> >> Cheers >> >> Giovanni >> > >> > What are all the time_t -> double changes for? That seems very wrong.. >> > >> There are double -> time_t changes, not the reverse. > > That way round also seems wrong.. surely it needs more than changing > the variable type - what about places where the value from this is > printed, etc? > > Let's see if we can get the patches down to only things that are > needed for packaging/directory changes, and for things which should > go upstream - mostly format string fixes for printing time_t, which > should use %lld and cast the time_t value to (long long). i.e. > avoid other local patches. > > Diff below mostly does that (though I haven't touched the iovec changes, > I'm not sure what they are for, any idea?) and works for me (and the > timings/delays seem reasonable) on amd64 and macppc. > > Lots of cvs add/rm's, so I've also included a tar of the ports dir > in case that's easier to test.
I still think that the assert trap in timing.cc is only due to floating point quirks, not to erroneous calculations. Use assert(diff <= interval + FLT_EPSILON); and the assert isn't triggered anymore. And this is the way the test should be done imho. I only get this trap on i386: macppc and sparc64 with their different fp implementations are perfectly happy. I'll take a look at the rest of the update tomorrow. -- jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE (previous: 0x06A11494 / 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494)
