[C-safe-secure-studygroup] Bounds-checked interfaces

[Wilson, Charles]

Without seeing a direct quote from Clive, I can only comment on the general principle.

Any code, whether new or modified, creates opportunities to inject new defects. The point being that, on its face, this is a statement which serves to justify not addressing technical debt. Writing code is a dangerous business requiring sound design, implementation and verification. I know people who I would trust to modify “working” code and other I would not entrust the task of microwaving popcorn.

From: C-safe-secure-studygroup [mailto:c-safe-secure-studygroup-bounces at lists.trustable.io] On Behalf Of Robert Seacord
Sent: Wednesday, January 16, 2019 1:46 PM
To: C Safety and Security Study Group Discussion <C-safe-secure-studygroup at lists.trustable.io>; Clive Pygott <Clive.Pygott at ldra.com>
Subject: [C-safe-secure-studygroup] Bounds-checked interfaces

I'm working on a paper on bounds-checked interfaces that I'm going to solicit reviewers for soon.
Meanwhile, I've heard Clive defend the following principle:

This is a widely-held expert view that changes to “working code” only increase the opportunities to inject new defects.  This view has even been expressed by the safety-critical community.

I'm wondering if there is an authoritative source I could reference on this claim?

I'm tempted just to write "Clive says...."  ;^)

Thanks,
rCs
---
This communication contains confidential information. If you are not the intended recipient please return this email to the sender and delete it from your records.

Diese Nachricht enthaelt vertrauliche Informationen. Sollten Sie nicht der beabsichtigte Empfaenger dieser E-mail sein, senden Sie bitte diese an den Absender zurueck und loeschen Sie die E-mail aus Ihrem System.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/c-safe-secure-studygroup/attachments/20190116/b1928b62/attachment.html>