[time-nuts] GPS Outage
Bob Camp
kb8tq at n1k.org
Tue Mar 1 07:35:10 EST 2016
Hi
Take a look at math libraries and things like printf libraries. Each time somebody
writes one, there are a group of bugs that come up again and again. Yes, you
would *think* each group would come up with creative *new* errors … not so much.
There are always obvious assumptions that turn out to be wrong in corner cases.
Bob
> On Mar 1, 2016, at 1:56 AM, Magnus Danielson <magnus at rubidium.dyndns.org> wrote:
>
>
>
> On 02/29/2016 11:31 AM, Martin Burnicki wrote:
>> Hal,
>>
>> Hal Murray wrote:
>>>
>>> martin.burnicki at 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. Modern approaches to testing helps, and working on the backlog of testing can help to disclose such problems, but only if the test-code writer has the mindset that covers the problem at hand. It's easy to make bold statements, reality is much more humbling experience in the long run. Good test-benches will aid you as you want to make larger clean-ups of old code. Larger clean-ups helps to expose old bugs as you actually look at the code as a designer again. It is also humbling to see what errors a younger yourself did and how you now don't do such design anymore as you have been bitten badly by the bug.
>
> Cheers,
> Magnus
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
More information about the time-nuts
mailing list