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 <[email protected]> > wrote: > > > > On 02/29/2016 11:31 AM, Martin Burnicki wrote: >> Hal, >> >> Hal Murray wrote: >>> >>> [email protected] 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 -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
