[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