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
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
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
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
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.
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
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];
In all the rules' code samples that declare functions, make sure that parameters that are not changed in the function are marked const.
- done - alexv 4/22
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