Hi Albert,

Actually the second issue relating to the variable last_change not being a 
static is NOT specifically related to how dnsmasq handles time.  Without the 
static definition of last_change, the "if(difftime(statbuf.st_mtime, 
last_change)" ALWAYS evaluates to > 0, which is not what the code was intended 
to do.  I believe the intent of this code is to avoid unnecessary calls to 
reload_servers()... in other words, if there has been no time elapsed since we 
last reloaded the servers, then we shouldn't do it again.  The result of the 
difftime() in this case should be the number of seconds since dnsmasq last did 
the reload_servers.  With the broken code, the difftime() ALWAYS resulted in 
the number of seconds between time 0 (the initialized value of last_change) and 
the timestamp on the /etc/resolv.conf file... and consequently, this would 
ALWAYS result in a call to reload_servers(), whether it was needed or not.  I 
don't consider this a major issue.. with the broken code, it just means that 
there may be an extra reload_servers done here and there.

The issue with the current time being potentially less than current timestamps 
in dnsmasq() is an issue in dnsmasq in general and comes into play whenever 
difftime() is used to determine elapsed time.  In most uses of difftime, the 
code assumes current time is greater than any cached time; when current time is 
less than the cached timestamp, the code has issues.  As I pointed out 
previously, I saw only one use of difftime() where the code actually took into 
consideration that the current time might be less than cached timestamp... all 
other uses of difftime MAY have issues when result of difftime is negative.  
With the impact of ntp, it is possible that the time goes backwards on the 
router, such as might happen with daylight savings time in the fall, when 
clocks are adjusted backwards in the USA by one hour... or when the clock on 
the router is not right and ntp corrects it.

I hope this clarifies what I was trying to say.


__________________________________________________________________ Confidential 
This e-mail and any files transmitted with it are the property of Belkin 
International, Inc. and/or its affiliates, are confidential, and are intended 
solely for the use of the individual or entity to whom this e-mail is 
addressed. If you are not one of the named recipients or otherwise have reason 
to believe that you have received this e-mail in error, please notify the 
sender and delete this message immediately from your computer. Any other use, 
retention, dissemination, forwarding, printing or copying of this e-mail is 
strictly prohibited. Pour la version française: 
http://www.belkin.com/email-notice/French.html Für die deutsche Übersetzung: 
Dnsmasq-discuss mailing list

Reply via email to