[Dnsmasq-discuss] (no subject)

[Jan 'RedBully' Seiffert]

Simon Kelley wrote:
> Jan 'RedBully' Seiffert wrote:
> 
>> hmmm, or not? Rules of implicit type conversion...
>> Is the difftime result casted to an int or the int casted to a double:
>> Good?
>>
>>> ./src/rfc2131.c:976:  else if (lease && lease->expires != 0 &&
>>> difftime(lease->expires, now) > 0.0)
>>
>> Bad?
>>
>>> ./src/lease.c:251:      if ((lease->expires != 0 && difftime(now,
>>> lease->expires) > 0) || lease == target)
>>
>>
>> Simon?
> 
> My understanding  is that both of those work to determine which of the
> tho timevals is larger. I don't think you can be sure to eliminate all
> FP operations in either case by wrapping difftime. All of this is just a
> portable way to find the order of two time_t variables.

Oh, i was not asking you to eliminate the FP, I'm "fine" with it, this
solution was just a hint for mmarkk.

I was just asking myself, if the implicit type conversion in:
difftime(now, lease->expires) > 0
(note the int to the right) would do the right thing. But i think so. 1
sec. difference will lead to 1.0 (according to the man page), which
gives us 1 > 0 (0.99 would become 0 > 0 == false).

I'm with you on the portability point here. difftime is the API they
give us, so let's use it, since it is clearly stated, time_t don't have
to be an arithmetic type, maybe a struct/union/something (opaque).
So i was _not_ asking to change that, 64 Bit time_t will come, sooner or
later.

Pro: portability
Con: FP-bloat
Stick to the API, recompile, be happy.
Portability wins

Only mentioned it as a hack to get things going, you know, sometimes you
have to be pragmatic and make a compromise. (But leave a comment for the
next one! ;)

> It's a pity there isn't a way to do that portably without involving FP.
> 
Hmmm, sigh, yes, there's cleanly a gap (i mean, that's a quite common
task and a double for this??...). On the other hand, what return type
should a standard choose given that time_t can be complex/large...


> 
> Cheers,
> 
> Simon.
> 
> 
Greetings
	Jan

-- 
error compiling committee.c: too many arguments to function