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

Fulvio Baccaglini fbaccaglini at perforce.com
Thu Jan 17 12:02:48 GMT 2019

From: C-safe-secure-studygroup <c-safe-secure-studygroup-bounces at lists.trustable.io> on behalf of Robert Seacord <rcseacord at gmail.com>
Sent: 17 January 2019 11:13
To: Clive Pygott
Cc: C Safety and Security Study Group Discussion
Subject: Re: [C-safe-secure-studygroup] Bounds-checked interfaces

That quote will do.  ;-)  Is that just old folksy programmer wisdom or is it written down somewhere?

==> There is something along those lines mentioned in the context of MISRA Compliance:2016:

"A project that attempts to check for compliance late in its lifecycle is likely to spend a considerable amount of time in re-coding, re-reviewing and re-testing, and it is easy for this rework to introduce defects by accident. Code shall be checked for compliance as it is developed and not as part of a “tick-box” exercise to be completed as part of the final delivery phase. If a project is building on code that already has a proven track record, then the benefits of gaining compliance by refactoring existing code may be outweighed by the risks of introducing a defect. In such cases a judgement needs to be made based on the net benefit likely to be obtained." (there are also similar sentences in MISRA C:2012)

On Thu, Jan 17, 2019, 4:24 AM Clive Pygott <clivepygott at gmail.com<mailto:clivepygott at gmail.com> wrote:
I think I'd like to see what it is I'm supposed to have said, before you start something as 'Clive says...'!

What is recognized is that if something has been working for sometime without issues, its a bad idea to force it to be changed to meet some new standard, usually known as 'grandfather rights'.


On Wed, Jan 16, 2019 at 6:46 PM Robert Seacord <rcseacord at gmail.com<mailto:rcseacord at gmail.com>> wrote:
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...."  ;^)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/c-safe-secure-studygroup/attachments/20190117/fbcf1743/attachment.html>

More information about the C-safe-secure-studygroup mailing list