Nut upsdev - Jan 2010 - [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

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/warnings
Historically, 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