CERT C Secure Coding Standard - last call for reviewers

[pete]

pete said:



How do you write to a file without
calling a function (or function-like macro)?

I don't know.
Why do you ask?

 

[Keith Thompson]

[Followups set to comp.lang.c]

Robert Seacord said:

We would like to invite the C community to review and comment on the
current version of the CERT C Secure Coding Standard available online at
www.securecoding.cert.org <http://www.securecoding.cert.org> before
Version 1.0 is published.

Here are my comments on the preprocessor section, PRE00-A to PRE31-C.

These comments can also be found at
http://www.cpax.org.uk/prg/portable/c/reviews/seccode.php [...]
PRE07-A. Avoid using repeated question marks

The point of this advice is to protect you from accidental trigraphs! And
of course it's sound advice. The example, though, is an interesting one.
It introduces a problem for which the blame should probably be shared
about evenly between single-line comments and trigraphs, and presents a
solution in which both have been eliminated. I'm not complaining about
this, but it seems to lack focus. (Note that the simplest fix would have
been the introduction of a space after, or even just the removal of, the
second question mark.)

If you don't use trigraphs, see if you can get your implementation to
disable them. (Some do this by default - you actually have to turn them
on, rather than off.) If you can't disable them (either because your
implementation won't let you or because you do actually use them), it's
worth grepping your source code occasionally in search of trigraph
sequences, so that you can decide on a case-by-case basis whether you
intended to use a trigraph in that situation.

[...]

Disabling trigraphs isn't necessarily a good idea. A fully conforming
C compiler (C90 or C99) must process trigraphs, and needn't provide a
way to disable them. If you disable them for you own work, you risk
using them accidentally and writing code that behaves differently when
somebody else compiles it.

Instead, see you can get your implementation to warn you about
trigraphs, so you can avoid putting them into your code in the first
place.

(I wonder which is more common in real-world code, deliberate use of
trigraphs or accidental use of trigraphs.)

 

[Richard Heathfield]

Keith Thompson said:

(I wonder which is more common in real-world code, deliberate use of
trigraphs or accidental use of trigraphs.)

Number of times I've accidentally trigraphed: 0 IIRC
Number of times I've deliberately trigraphed in real-world code: N

(for very large N).

 

[pete]

I don't know.
Why do you ask?

These are all the kinds of side effects:
1 object modification
2 volatile access
3 file write
4 function call that results in one or more of the previous three.

You agreed with:

PRE31-C. Never invoke an unsafe macro with
arguments containing assignment,
increment, decrement, or function call

suggesting that there's something wrong with a program like new.c.

There's nothing wrong with new.c.

/* BEGIN new.c */

#include <stdio.h>

FILE *f(void);

int main(void)
{

#ifdef putc
putc( 'X', f());
putc('\n', f());
#else
puts("putc isn't a macro right here and now.");
#endif

return 0;
}

FILE *f(void)
{
return stdout;
}

/* END new.c */

 

[Richard Heathfield]

pete said:

You agreed with:

I wrote:

"By 'unsafe macro', SECCODE means a macro that evaluates at least one of
its arguments more than once. It is clearly a bad idea to pass to such a
macro any argument that has side effects."

suggesting that there's something wrong with a program like new.c.

s/something/nothing/ since f() has no side-effects, and in any case it's
not clear that putc evaluates any of its arguments more than once.

<snip>

 

[Gerry Ford]

Keith Thompson said:



Number of times I've accidentally trigraphed: 0 IIRC
Number of times I've deliberately trigraphed in real-world code: N

(for very large N).

When I thought, recently, to have seen a trigraph, I saw two question marks
without intervening tokens. The query syntax is what would be identified as
a trigraph by a person who reads both directions indiscrimately.

The explanation comes from the octal and binary. 100 squared is ten
thousand.

 

[pete]

pete said:



I wrote:

"By 'unsafe macro',
SECCODE means a macro that evaluates at least one of
its arguments more than once.
It is clearly a bad idea to pass to such a
macro any argument that has side effects."

And then you wrote in the next sentence in the same paragraph:

The four side effects that are
singled(?!) out in the title are in fact the only four I can think of
but if you do manage to think of any others, don't pass those to
macros either, okay?

Which is the fourth side effect singled(?!) out in the title?

It looks like "function call",
as though you mean to say
that a function call is a side effect.

 

[Keith Thompson]

Keith Thompson said:


Number of times I've accidentally trigraphed: 0 IIRC
Number of times I've deliberately trigraphed in real-world code: N

(for very large N).

Interesting.

Number of times I've accidentally trigraphed: None that I know of, but
who knows??!

Number of times I've deliberately trigraphed in real-world code: 0

I suspect (with no real evidence) that my trigraphing pattern is more
common than yours. In particular, I suspect that most real-world
trigraph use has been on ECBDIC-based mainframes (that's where you
used trigraphs, right?), and that most C programmers haven't used C on
EBCDIC-based mainframes. (Either or both suspicions could easily be
mistaken.)

I do wish that the inventors of trigraphs had come up with a way to
indicate at the top of a source file that it contains trigraphs, with
trigraphs being ignored (so sizeof "??!" == 4) unless they're
explicitly enabled. Something like:

??=pragma STDC TRIGRAPHS ON

Of course the need to use "??=pragma" creates a bit of a
chicken-and-egg problem, but that could have been solved.

It's too late now, of course; we can't break code written since 1989
that has used trigraphs in good faith. But it would be nice if
compilers warned about, say, trigraph sequences that appear in string
literals in source files that don't contain trigraphs outside string
literals, a strong indication that the programmer really wanted a
double question mark.

 

[Richard Heathfield]

pete said:

And then you wrote in the next sentence in the same paragraph:


Which is the fourth side effect singled(?!) out in the title?

It looks like "function call",
as though you mean to say
that a function call is a side effect.

You make a fair point. (The review was, after all, written at a ridiculous
time of day!)

In the Web version of this review, I have inserted the following paragraph:

"Note, by the way, that function calls only have side effects if they have
side effects! They are not required to, obviously. There is no particular
problem with passing, say, sin(x) to an 'unsafe' macro, although of course
there will be a minor performance penalty associated with the multiple
evaluation."

Will that suit?

 

[Richard Heathfield]

Keith Thompson said:

Richard Heathfield <[email protected]> writes:

Interesting.

Number of times I've accidentally trigraphed: None that I know of, but
who knows??!


Number of times I've deliberately trigraphed in real-world code: 0

I suspect (with no real evidence) that my trigraphing pattern is more
common than yours.

Oh, I'm sure of it (again, with no real evidence).

In particular, I suspect that most real-world

trigraph use has been on ECBDIC-based mainframes (that's where you
used trigraphs, right?),

Right.

<snip>

 

[Hallvard B Furuseth]

The first three are only one kind of side effect: assignment.

And taking an hour to execute is not a side effect, but still a good
idea to not repeat.

 

[pete]

pete said:

You make a fair point.
(The review was, after all, written at a ridiculous
time of day!)

In the Web version of this review,
I have inserted the following paragraph:

"Note, by the way,
that function calls only have side effects if they have
side effects! They are not required to, obviously.
There is no particular problem with passing, say,
sin(x) to an 'unsafe' macro, although of course
there will be a minor performance penalty
associated with the multiple evaluation."

Will that suit?

Imprimatur!

 

[Martin]

[...] Worse still, the name is misleading -
char * is not a synonym for string in C,
and to suggest (via the typedef) that it is,
is a disservice to the code reader.

I agree with you, but K&R2 Section 6.7 (Typedef) contains this:

Similarly, the declaration

typedef char *String;

makes String a synonym for char * or character pointer, which may then
be used in declarations and casts:

String p, lineptr[MAXLINES, alloc(int);
int strcmp(String, String);
p = (String) malloc(100);

My point being, that K&R2 is regarded by many as one of the C language's
premier text books, and there we have it showing String as a synonym for
char *. (Yes, I know the casting of malloc in K&R2's example is
ill-advised.)

 

[lawrence.jones]

(I wonder which is more common in real-world code, deliberate use of
trigraphs or accidental use of trigraphs.)

The obvious place to go for answers to such questions is Derek Jones's
Economic and Cultural Commentary on the C Standard
(<http://www.knosof.co.uk/cbook/cbook.html>). Unfortunately, it doesn't
address this question other than to note:

There are insufficient trigraphs in the visible form of the .c
files to enable any meaningful analysis of the usage of
different trigraphs to be made.

and:

The visible form of the .c files contained 593 (.h 10) instances
of two question marks (i.e., ??) in string literals that were
not followed by a character that would have created a trigraph
sequence.

None of the trigraph sequences seem particularly likely to occur
accidentally, although one could certainly claim that ??! and ??) should
be expected to crop up occasionally. Since there are people who
deliberately use trigraphs, I would expect deliberate use to be more
prevalent than accidental use, but I have no hard data to back that up.
(And I'm disappointed [and a little surprised] to find that Derek
doesn't, either. Not that I'm criticizing, mind you; at 1600+ pages,
one can hardly accuse him of being a shirker!)

-Larry Jones

I'm not a vegetarian! I'm a dessertarian. -- Calvin

 

[Ioannis Vranos]

We would like to invite the C community to review and comment on the
current version of the CERT C Secure Coding Standard available online at
www.securecoding.cert.org <http://www.securecoding.cert.org> before
Version 1.0 is published. To comment, you can create an account on the
Secure Coding wiki and post your comments there.

Our intent is to complete major development of Version 1.0 by April 18,
2008, with the published version of the standard being available in
September. Once Version 1.0 of the standard goes to the publisher, we
will begin development of Version 2.0. That is, we will continue to
maintain the wiki to further advance the "working version" of the CERT C
Secure Coding Standard. The published 1.0 version will become the
official version, until replaced by a future version. It is unlikely a
subsequent version will be released any time in the next 2-3 years, so
we would like to ensure that Version 1.0 will be a high quality product
that will promote and encourage secure coding practices.

Thanks for any help and assistance you have already provided and for any
additional contribution you may make. There are currently 184
individuals who have contributed to the development of this standard,
without whom this effort could not have succeeded.

I saw you have an equivalent C++ standard, but there isn't such a post
in comp.lang.c++. I would like to see a relevant post there.


Also is there any PDF including all the stuff in one place, instead of
15+ files?

 

[rCs]

comments below.

I saw you have an equivalent C++ standard, but there isn't such a post
in comp.lang.c++. I would like to see a relevant post there.

we've posted in the past. right now we are focused on finalizing the
C standard for publication. once we have completed this, we will turn
our attention more fully to the C++ standard. of course, you are more
than welcome to review and comment on the C++ standard at this time;
we might be a little slower than usual in responding.

rCs

 

[rCs]

We've updated "PRE31-C. Never invoke an unsafe macro with arguments
containing assignment, increment, decrement, volatile access, or
function call" and other rules and recommendations in this section
based on your feedback.

Feel free to have another look:

PRE31-C: https://www.securecoding.cert.org/confluence/x/agBi

Preprocessor (PRE): https://www.securecoding.cert.org/confluence/x/KAQ

Thanks,
rCs

 

[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

 

[Douglas A. Gwyn]

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.