Hi Jim,
On 03/01/2016 03:24 PM, jimlux wrote:
On 2/29/16 10:56 PM, Magnus Danielson wrote:
On 02/29/2016 11:31 AM, Martin Burnicki wrote:
Hal,
Hal Murray wrote:
martin.burni...@burnicki.net said:
Strange that at least 3 independant firmware trees/development
teams should
chose the same magic wk860.
I don't find it strange. If the next firmware version is based on the
previous version and none of the developers has stumbled across this
potential problem earlier ...
That sounds like poor software engineering. Or poor engineering
management.
The wk860 is supposed to represent the build time of the software ...
Do you *know* this, or are you just *assuming* this? ;-)
so it will
work for 20 years from when it was built rather than 20 years from
when the
10 bit week counter last rolled over or 20 years from when the
constant was
last updated.
There are also approaches where the proper extension of a week number
doesn't just work within a single 1024 week cycle with some hardcoded
limit, like this simple example:
if ( wn < 860 )
wn += 1024;
There may always be pieces of code which generate a faulty result under
certain conditions, and no stumbles across this even in reviews until it
really happens.
I'm not aware of *any* project where each single line of code is checked
once again whenever a new release is rolled out.
Rather, in all projects I've seen there is a tendency to trust existing
code and only extend it. Re-validating it is usually regarded as money
in the sea. That old code can have incorrect assumptions that you
eventually expose as you change its environment is a re-occurring
learning experience.
Ariane 5...
Indeed. Most of the cases the failure isn't as spectacular.
Cheers,
Magnus
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
