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 |
...
. | |
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} |
)
review -> review + review-one -> review + review-two -> No tags
significant changes -> review or incomplete
There is some inconsistency with the use of const. We used to have a recommendation that declarations appear like this:
| Code Block |
|---|
int const *ip;
|
But we eventually got rid of it. Most of our declarations are of this form, but some are of this form:
| Code Block |
|---|
const int *ip;
|
The argument we had was that the first form is less prone to error, but the second form is widely used, and not something that people will change.
Our choices are a) apply the first style consistently, b) apply the second style consistently, c) allow a mix of both styles.
Whatever style we adopt should also apply to other qualified type declarations, like volatile.
The bot changes all of these to have rightmost const. There are very few (if any, it would only be what was added recently) the other way. -jp
C++ has it's own TODO List
Pages now have tags to indicate the status of their corresponding checker in Compass Rose:
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 |
size_toperated on multiple files at once. | |
ROSE could enforce this rule, but could not avoid catching some false positives. |
At this point, all rules with priority level L1 or L2 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.
...