Fix for mktime() issue

[eponymous alias]

--- On Tue, 3/16/10, Ton Voon <ton.voon at opsera.com> wrote:
> In t-tap/test_timeperiods.c, I've got tests for a specific
> case of  
> what happened over the DST change in the autumn. Adding
> the  
> tm_isdst=-1 gives errors, whereas undefined works.

Huh???  There's no such thing as undefined
in C.  There's a bit pattern of some sort
in that data cell, you'd better believe it.
Deliberately blinding yourself to what it
is just leaves you open to all manner of
potential mischief when it sometimes turns
out not to contain what you expect it to.

> What I don't have, are tests for the other 18 cases where
> is_dst has  
> been initialised, and so I didn't revert those other
> changes. But my  
> opinion is now that this is too cautious and we should just
> revert  
> back to Nagios pre-3.2.0 behaviour.
> 
> So what I am proposing is:
>    * remove all the is_dst initialisations
> (because I don't want to  
> add new test cases and this is a recent change and Nagios
> didn't have  
> issues here before)

That's a recipe for disaster, introducing
deliberate ambiguity into the calculation.

>    * only add specific cases back when there
> is a test case that  
> proves that it should be initialised
> 
> The only way to prove this is running tests. Maybe some
> platforms  
> implement POSIX different. The best way to tell is to have
> test cases  
> that run on your system of choice and report to Tinderbox.

If you don't trust the mktime() implementation, then a few test
cases run outside of Nagios itself should
be able to prove that before the software
is even built.  And maybe that should either
break the build, or force the build to emit
a strong warning that the software will be
unreliable on this platform.  And all of
that should trigger bug reports to the
upstream maintainers of mktime().


      

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev