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

Wilson, Charles Charles.Wilson at draeger.com
Thu Jan 17 18:59:52 GMT 2019


Though that might be the case.

I’ve done a bit of scrounging over the years to try to make the case for Annex K, but have never found any positive feedback. It is either dismissed as a Microsoft-ism, which is unfortunate, or ignored because of the lack of ease to implement. The only neutral evaluation I’ve seen is Martin’s.

To be honest, it’s easier to justify implementing the checks manually based on Coverity (or other static analysis tool) detection.

In C++, I just tell people to stop using the C standard library.

From: Robert Seacord [mailto:rcseacord at gmail.com]
Sent: Thursday, January 17, 2019 1:54 PM
To: Wilson, Charles <Charles.Wilson at draeger.com>
Cc: C Safety and Security Study Group Discussion <c-safe-secure-studygroup at lists.trustable.io>; Clive Pygott <Clive.Pygott at ldra.com>
Subject: Re: [C-safe-secure-studygroup] Bounds-checked interfaces

Yeah, I think he may have wrote that.  ;^)

On Thu, Jan 17, 2019 at 12:52 PM Wilson, Charles <Charles.Wilson at draeger.com<mailto:Charles.Wilson at draeger.com>> wrote:
Have you seen:

Updated Field Experience With Annex K - Bounds Checking Interfaces (2015)
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1969.htm

I've generally experienced a great deal of pushback as uptake of Annex K requires considerable code change.

-----Original Message-----
From: C-safe-secure-studygroup [mailto:c-safe-secure-studygroup-bounces at lists.trustable.io<mailto:c-safe-secure-studygroup-bounces at lists.trustable.io>] On Behalf Of Martin Sebor
Sent: Thursday, January 17, 2019 10:59 AM
To: C Safety and Security Study Group Discussion <c-safe-secure-studygroup at lists.trustable.io<mailto:c-safe-secure-studygroup at lists.trustable.io>>; Robert Seacord <rcseacord at gmail.com<mailto:rcseacord at gmail.com>>; Clive Pygott <Clive.Pygott at ldra.com<mailto:Clive.Pygott at ldra.com>>
Subject: Re: [C-safe-secure-studygroup] Bounds-checked interfaces

What guidance do safety expertes give to programmers of safe systems for the adoption of the APIs (Annex K)?

I'm especially wondering what the recommended practice is for handling constraint violations (abort vs return to caller) and exercising handler code.

Martin

On 1/16/19 11:46 AM, Robert Seacord 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...."  ;^)
>
> Thanks,
> rCs
>
> _______________________________________________
> C-safe-secure-studygroup mailing list
> C-safe-secure-studygroup at lists.trustable.io<mailto:C-safe-secure-studygroup at lists.trustable.io>
> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-safe-secure-stud
> ygroup
>


_______________________________________________
C-safe-secure-studygroup mailing list
C-safe-secure-studygroup at lists.trustable.io<mailto:C-safe-secure-studygroup at lists.trustable.io>
https://lists.trustable.io/cgi-bin/mailman/listinfo/c-safe-secure-studygroup
---
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/20190117/0792a975/attachment.html>


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