On 29/04/2018 11:01, Gareth's Downstairs Computer wrote:
> On 29/04/2018 10:14, Ahem A Rivet's Shot wrote:
>> On Sat, 28 Apr 2018 19:43:36 +0100
>> Gareth's Downstairs Computer
>>  wrote:
>>
>>> For example, I was contracted to work on the development
>>> of a CANBus steering mechanism which used one of the
>>> object repository. When I wished to check the efficacy
>>> of my proposed changes by drilling down to everything
>>> that would be affected by the change, I was refused access
>>> to the source of the already implemented classes.
>>
>>     Makes sense, code should be built to the spec of the underlying
>> libraries and not to the implementation. If behaviour outside the spec
>> matters it needs to be bought into the spec, and preferably tested for.
> 
> It is lack of knowledge of the implementation that hides bugs.

No, it's lack of testing.

There will always be a limit to how far you can drill down through the 
software stack, firmware, microcode, and hardware implementation, and an
even bigger limit on how much of that you can really understand by 
itself, and as a complete system. The only way to know if the entire 
system behaves in the way you want it, is to test it thoroughly.

There are completely open source projects that have been around for 20+ 
years, had thousands of eyes on them, and were thought to be of a pretty
good quality by those who understood the implementation inside out. Then
new fuzzing test tools came along, throwing all sorts of unexpected 
inputs at the code, and a huge number of bugs were exposed.

---druck

--- SoupGate-Win32 v1.05