Tags (Labels)
Tag | Meaning |
|---|---|
Pages that form the main sections of this standard and that are listed in the Section Index on the SEI CERT C Coding Standard page. | |
Guidelines with links to a rule in 6 The Void. The link should be removed. | |
Guidelines that have been significantly changed since the checker was coded. The checker needs updating. | |
Pages that need work. | |
...
Pages that need to be |
...
deleted. See also void below. | |
Pages that have problems with the citations at the bottom |
...
. |
...
review -> review + review-one -> review + review-two -> No tags
significant changes -> review or incomplete
Pages with comments that might make good sidebars. | |
Guidelines in other CERT secure coding standards (residing in other Wiki spaces) that might make good C guidelines. Port to C those rules that are truly applicable. | |
Guidelines that might be candidates for adoption in the SEI CERT Oracle Coding Standard for Java. | |
Pages tagged for elimination from the standard and that are listed in 6 The Void. |
ROSE-Specific Tags (Labels)
Pages now have tags (also known as
| Wiki Markup |
|---|
{doc://display/DOC/Working with Labels Overview}Labels{doc} |
)
Functions have no parameters should be declared as void so as to document that this is intentional.
for example,
| Code Block |
|---|
void abort(void);
|
Run spider with new changes.
Incomplete pages in C++ use their own incomplete-cpp tag.
Incomplete pages in Java use their own incomplete-java tag.
Pages now have tags to indicate the status of their corresponding checker in Compass Rose.
Complete rules are tagged :
Tag | Meaning |
|---|---|
...
ROSE catches all violations | |
...
ROSE catches some violations | |
...
ROSE could catch some or all violations, but doesn't yet. | |
ROSE doesn't catch violations, but will soon, | |
These rules can't be checked automatically. | |
These rules could be checked automatically in theory, but not by ROSE. | |
ROSE could check these rules if it recognized macro usage. | |
ROSE could check these rules if it operated on multiple files at once. | |
ROSE could enforce this rule, but could not avoid catching some false positives. |
At this point, all rules should have one of these tags. That is, they should be completely or partially checked by ROSE, or they should be marked 'rose-possible', in that we will try to check them with ROSE, or they should have one of the nonapplicable tags indicating we don't think they can be checked with ROSE
- FLP02 is missing a risk assessment
Rule/Recommendation about floating point exceptions
- what in particular should be written about these? should this go under Signals b/c of SIGFPE or under FLP02 as that is already started? - alexv 4/15
I thought Abhijit Rao was going to replace FLP02-A with FLP03-A. Detect and handle floating point errors, but instead he create a new recommendation.
I think the plan should be to consolidate these two recommendations into FLP02-A. This will also solve the problem that "FLP02 is missing a risk assessment"
I've looked at some of the C rules and recommendations, and here are my
recommendations 
for copying them across to C++.
DCL05-A - OK more-or-less as is.
DCL06-A - OK more-or-less as is.
DCL07-A - needs rethinking for C++.
DCL09-A - not appropriate for C++ because of ERR00-A.
DCL10-A - needs some reworking for C++ (note that ISO/IEC 14882-2003
does not use the term "variadic function").
DCL11-A - ditto.
DCL12-A - perhaps needs reworking for C++.
DCL30-C - needs reworking for C++.
DCL32-C - what are the C++ requirements on identifier length?
DCL33-C - not applicable?
DCL34-C - OK more-or-less as is.
DCL35-C - OK more-or-less as is, but need to change printf's in CS.
DCL36-C - needs reworking for C++.
EXP00-A - OK more-or-less as is.
EXP01-A - needs different examples.
EXP03-A - needs different examples.
EXP04-A - OK more-or-less as is.
EXP07-A - needs rethinking for C++.
EXP08-A - perhaps already covered by OBJ30-C.
EXP09-A - OK more-or-less as is.
EXP34-C - perhaps covered by DAN34-C.
EXP35-C - this appears to require some rethinking anyway.
EXP36-C - needs some thought for C++.
INT00-A - needs reworking for C++.
INT07-A - needs reworking for C++.
INT30-C - needs reworking for C++.
INT35-C - needs reworking for C++.
INT37-C - needs reworking for C++.
That's as far as I got.
By "OK more-or-less as is" I mean that it can be copied over as it is
but the references to C and the C Standard clearly must be changed to
C++.
When you copy this rule over to the C++ side:
FIO34-C. Use int to capture the return value of character IO functions
Be sure to add something about istream::get() which return int values, not char values.
...
It might also be worth giving these another look.
...