bogus timing calculation in gcrypts benchmark

[Tobias Ulmer]

Hi there,

I've had a look at the catastrophic results of gcrypt on BSD systems
posted here:
http://www.phoronix.com/scan.php?page=article&item=linux_bsd_opensolaris&num=3

It turns out that this is due to a number of bugs in benchmark.c.
It uses CLOCKS_PER_SEC, which on BSD systems is the actual tick rate,
but on "XSI conformant" systems, it's always 1000000. (Have a look into
bits/time.h on a glibc system, the definition violates ANSI C...).

The second bug is the "ms" unit, I guess it should haven been "us".

If we assume that the unit is microseconds, then there's a 0 too many in
the scaling factor.

So here's a patch that should be as portable as it gets, with a sane
millisecond resolution. Tested on OpenBSD and Linux

Tobias

PS: please CC

--- tests/benchmark.c.orig	Thu Apr  2 11:25:34 2009
+++ tests/benchmark.c	Sat Mar  6 23:40:05 2010
@@ -27,6 +27,7 @@
 #ifdef _WIN32
 #include <windows.h>
 #else
+#include <unistd.h>
 #include <sys/times.h>
 #endif
 
@@ -332,8 +333,9 @@
   t = (t2 - t1)/10000;
   snprintf (buf, sizeof buf, "%5.0fms", (double)t );
 #else
+  long ticks = sysconf(_SC_CLK_TCK);
   snprintf (buf, sizeof buf, "%5.0fms",
-            (((double) (stopped_at - started_at))/CLOCKS_PER_SEC)*10000000);
+            (((double) (stopped_at - started_at))/ticks)*1000);
 #endif
   return buf;
 }