Re: CERT C Secure Coding Standard - last call for reviewers

[John Nagle]

I hadn't read this before, but I just came back from the
Embedded Systems Conference, where three vendors were selling
checking tools to find bugs in real-time C code. Sometimes
they can detect array bounds errors by static analysis. But
the approaches used aren't airtight.

Reading the "CERT C Secure Coding Standard" is interesting,
but a program compliant with the rules can still have memory
access violations. That's the trouble with viewing this as
a stylistic problem.

We could do much better, but would have to extend the C language
to do so. Is there any interest in that? C99 has a few halting
steps in the right direction, like the use of "static" in array
arguments in function declarations to indicate the minimum size
of the array passed. I've been writing up something in this area,
but unless there's serious political interest, it's not something
I would spend time on.

John Nagle
Animats

[CBFalconer]

John Nagle wrote:

>
I hadn't read this before, but I just came back from the Embedded
Systems Conference, where three vendors were selling checking
tools to find bugs in real-time C code. Sometimes they can
detect array bounds errors by static analysis. But the
approaches used aren't airtight.

.... snip ...

>
We could do much better, but would have to extend the C language
to do so. Is there any interest in that? C99 has a few halting
steps in the right direction, like the use of "static" in array
arguments in function declarations to indicate the minimum size
of the array passed. I've been writing up something in this
area, but unless there's serious political interest, it's not
something I would spend time on.

It's not feasible, because the requirements would either destroy
previously valid code, or slow the execution down to a crawl, or
both. Ada or Pascal will give you what you want (but watch out for
non-compliant Pascals, such as that used by Borland or in Delphi).

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.
** Posted from http://www.teranews.com **

[Douglas A. Gwyn]

John Nagle wrote:

I hadn't read this before, but I just came back from the
Embedded Systems Conference, where three vendors were selling
checking tools to find bugs in real-time C code. Sometimes
they can detect array bounds errors by static analysis. But
the approaches used aren't airtight.

Obviously they cannot be airtight and still permit all correct,
strictly conforming programs.

Reading the "CERT C Secure Coding Standard" is interesting,
but a program compliant with the rules can still have memory
access violations. That's the trouble with viewing this as
a stylistic problem.

Trying to address errors of (programmer) thought with automation
is futile. The best that such coding standards can hope to
achieve is to catch a large fraction of the mistakes that might
otherwise find their way into delivered products.

We could do much better, but would have to extend the C language
to do so. Is there any interest in that? C99 has a few halting
steps in the right direction, like the use of "static" in array
arguments in function declarations to indicate the minimum size
of the array passed. I've been writing up something in this area,
but unless there's serious political interest, it's not something
I would spend time on.

I would suggest that so long as C remains compatible with past
(correct) C source code, extensions won't guarantee anything.
Note that there have already been other guidelines (e.g. MISRA)
and "safer" libraries (one is described in a TR from WG14).

I am sure there is academic and perhaps commercial interest in
development of a *new* programming language that has safety
"built in" to a significantly greater extent. (Some PLs claim
that they are already that way.) Maybe your effort would be
better employed working on those.