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} |
) 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 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.
...
It might also be worth giving these another look
Pages that need work have an incomplete tag
Pages that need to be deleted have a deleteme tag.
| Wiki Markup |
|---|
A bunch of pages have screwed-up formatting, where some character, such as \[ (open-brace) is backslashed. This defeats its purposes of indicating a link. I've also seen this on open-braces. Someone needs to traverse the rules and clean these up. \-5/1 started cjohns (got as far as 06 Arrays) |
Talked to Robert... we are gonna rework the TMP section, and move it back into FIO - alexv 5/6
- TMP33-C. Temporary files must be removed before the program exits needs to be moved to the Void
- TMP32-C. Temporary files must be opened with exclusive access needs to be incorporated into TMP30-C. Temporary files must be dealt with in a secure manner and then moved to the Void
- TMP30-C. Temporary files must be dealt with in a secure manner needs a more generic name+feel
- 10. Temporary Files (TMP) needs to be incorporated into TMP30-C. Temporary files must be dealt with in a secure manner
- TMP00-A. Do not create temporary files in shared directories needs to be reworked
- remove the emphasis on jail
- mention some OS specific solutions regarding file permissions
- stay vague, we don't want our hands dirty with this one
- move TMP00-A. Do not create temporary files in shared directories to 09. Input Output (FIO)
- move TMP30-C. Temporary files must be dealt with in a secure manner to 09. Input Output (FIO)
- 10. Temporary Files (TMP) needs to be moved to the Void and we need to fix up the section numbering to accomodate
FIO43-C. Do not copy data from an unbounded source to a fixed-length array and STR35-C. Do not copy data from an unbounded source to a fixed-length array are the same rule, what's the deal? -alexv
In all rules, nullify free'd pointers. That is, add p = NULL; after instances of free(p);. Within reason of course...if p was local, and the next statement was return don't bother.
- i went through to try to implement this, and i'm finding that many of our code examples are ambiguous as to whether functions will end immediately following the last statement... would it be better to just always say p = NULL? regardless of whether or not we return? What about if the next operation is p = some_other_var? - alexv
Generally if the example code MAY do something else between the free() and return, it SHOULD have /* ... */. In which case you insert 'p = NULL' before the /* ... */. Code that MAY NOT do anything between the free() and return need no null-ification. Also, reassigning p to some other value immediately after a free also means you don't need p = NULL. The point here is to prevent p's old value from being re-used, esp. in code we don't control, and represent with /* ... */.
The Risk Assessment Summary tables for each section need to be updated (they are out of date with the actual rules). - I got as far as EXP07, which still has the risk assessment for EXP10
i went through on 4/15 and checked to make sure the section tables matched the rules... are we confident that the risk summaries in the rules are correct? -alexv 4/17
- FLP02 is missing a risk assessment
- FIO09 is missing a risk assessment
- DCL31 is missing a risk assessment
The list of sections in 00. Introduction do not match the order the pages go in via nav links. Is the list on 00Intro correct or is the nav order correct? -5/1 cjohns
Most likely the list order is correct. (IIRC the only cross-section nav links are from the last rule of a section to the first rule of the next section & back. -5/2 svoboda
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.
...