[mcculley]

> It will not be caught in development testing — who runs a test for 50 days?

You don't have to run the system for 50 days. You can simulate the environment and tick the clock faster. Many high reliability systems are tested this way.

[dezgeg]

IIRC the initial value for the jiffies time counter in Linux kernel is initialized at boot time to something like five minutes before the wraparound point, precisely to catch this kind of issues.

[bobmcnamara]

WinCE too

[hombre_fatal]

It uses a hardware clock, one that pauses during sleep. There is no tick.

If you wanted to see how time impacts the program, you'd prob change fns like calculate_tcp_clock to take uptime as an argument so that you could sanity check it.

[mcculley]

Yes. I do mean designing software to make it testable.

The code that uses that value can be run in an environment where that value can be controlled.

I have written code that does this same thing and built a test harness for it.

[adamtulinius]

We're talking about a company that produces the hardware their OS is running on. I'm sure they can find a way to make the hardware clock run faster.

[hombre_fatal]

Yeah, but if you're going to go through all that work because you have to foresight to test how clocks impact code, it would be simpler to stub and test the few functions that call the code (where the bug was). The bug wasn't in the hardware.

[sho_hn]

Heck, many video games are tested this way.