see: incomplete tag
Here is a rule that looks like it needs some work:
TMP30-C. Temporary files must be created with unique and unpredictable file names
For David: Can you add the malloc() example from the Mark Dowd Flash null pointer vul to MEM32-C. Detect and handle memory allocation errors
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
Alex consolidated all child pages containing only code samples into their respective rules. Some child pages now need to be deleted, they all have a deleteme tag. -svoboda
I deleted a file with a deleteme tag... it turned out to be a mistake. Can someone let me know when I can do this for real, and I'll go and delete the child pages? -rcs
- I was pretty confident i only added the tag to pages that were consolidated, perhaps i missed something, sorry - alexv
- ahh... i see what happened, even if the pages look the same, they are still included using a tag.. sneaky - alexv
- ok... I'm fixing the mess i made, everything with the tag should be safe to delete (both C and C++) - alexv
Oops, it seems that INT02-A isn't consolidated y et...deleting those pages won't work. So the task is really to consolidate these children pages into their parent pages and then delete the children, starting with INT02-A. -svoboda
- done for real this time - alexv
EXP32-C. Do not access a volatile object through a non-volatile reference does not appear to be consolidated yet either. I did delete a bunch of child pages that were. - rCs
- done - alexv
The following rule in the array section needs to be written:
ARR36-C. Do not subtract or compare two pointers that do not refer to the same array -started cjohns 4/8
cjohns: this looks done, can you verify and remove from TODO? or if more needs to be done, can you leave it as a comment? thx - alexv 4/17
Christina has just verified to me that this is done. -svoboda 4/25
The following rule needs to be completed.
ARR37-C. Do not add or subtract an integer to a pointer to a non-array object -started cjohns 4/8
cjohns: this looks done, can you verify and remove from TODO? or if more needs to be done, can you leave it as a comment? thx - alexv 4/17
Christina has just verified to me that this is done. -svoboda 4/25
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 forward backward navigation links between sections need to be checked and fixed. -started 4/25 cjohns
The main page of DCL has a forward button to the first recommendation. should they all have this? -4/25 cjohns
Rule/Recommendation about trap representations
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"
In all the rules, replace hard-wired 'magic' numbers with enums, as per DCL06-A
So take examples like:
char buff[50];
and change them to:
enum {buff_max = 50};
char buff[buff_max];
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.
MEM36-C. Do not store an address into an object with a longer lifetime says it is marked for deletion... does anything need to be done about this? should we move it to the void? -alexv 4/22