Charles Lepple
2010-Jan-25 13:21 UTC
[Nut-upsdev] [nut-commits] svn commit r2274 - trunk/common
On Jan 25, 2010, at 7:44 AM, Arjen de Korte wrote:> Author: adkorte-guest > Date: Mon Jan 25 12:44:52 2010 > New Revision: 2274 > > Log: > Fix compiler warning on FreeBSD[...]> + fprintf(stderr, "%4.0f.%06ld\t", difftime(now.tv_sec, > start.tv_sec), now.tv_usec - start.tv_usec);With the difftime() macro, wouldn't it be possible to just use a single %f (with appropriate field widths)? I know I need to fix the character encoding issue, but here's the latest from Buildbot on OS X: http://buildbot.ghz.cc/public/nut/builders/MacOSX-10.5/builds/0/steps/compile/logs/warnings
Arjen de Korte
2010-Jan-25 14:22 UTC
[Nut-upsdev] [nut-commits] svn commit r2274 - trunk/common
Citeren Charles Lepple <clepple op gmail.com>:>> + fprintf(stderr, "%4.0f.%06ld\t", difftime(now.tv_sec, >> start.tv_sec), now.tv_usec - start.tv_usec); > > With the difftime() macro, wouldn't it be possible to just use a > single %f (with appropriate field widths)?Although difftime() returns a (double) time difference, the parameters it takes are in (time_t) seconds. On many platforms, (time_t) is a 32-bit signed integer, so doing that would leave us without sub-second resolution. Therefor I prefer to use gettimeofday() here which returns (struct timeval) with a microsecond resolution, instead of time() which might return something with sub-second resolution, but in many cases won't.> I know I need to fix the character encoding issue, but here's the > latest from Buildbot on OS X: > > http://buildbot.ghz.cc/public/nut/builders/MacOSX-10.5/builds/0/steps/compile/logs/warningsHistorically, struct timeval would return the microseconds as a (long) value and only relatively recently this was changed to (suseconds_t). However, we could probably safely cast this to (long), which is large enough for the range we need here (0..1999998). Best regards, Arjen -- Please keep list traffic on the list