TODO List

Pages that need work have an incomplete tag.
Pages that need to be deleted have a deleteme tag.
Pages that need to be reviewed have an review tag.

For the spider. I also think we should change "The tool Compass Rose" to "Compass/ROSE" in all the "Automated Detection" sections.

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 rose-complete.
Partially complete rules are tagged rose-partial.
Rules that simply cannot be enforced by Rose are tagged rose-nonapplicable.
Rules that could be easily done in Rose are tagged rose-possible.

As per Douglas's comment EXP11-A. Do not employ pointer arithmetic on the internal contents of a structure has no business being in INT... should we move it to DCL? (Alternatively we need better examples that aren't solved by ARR37-C. Do not add or subtract an integer to a pointer to a non-array object)- alexv 5/14

I was delaying action on this because Dan Saks was going to work on it. -rCs

References at the bottom of rules need a lot of work, here are some problem pages (based on broken/non-existent links)

• PRE07-A. Avoid using repeated question marks
• PRE10-A. Wrap multi-statement macros in a do-while loop
• DCL14-A. Do not make assumptions about the order of global variable initialization across translation units
• FLP00-A. Consider avoiding floating point numbers when precise computation is needed
• FLP02-A. Understand the caveats of floating point exceptions
• ARR35-C. Do not allow loops to iterate beyond the end of an array
• STR01-A. Adopt and implement a consistent plan for managing strings
• STR06-A. Do not assume that strtok() leaves the parse string unchanged
• STR36-C. Do not specify the dimension of a character array initialized with a string literal
• SIG00-A. Mask signals handled by non-interruptible signal handlers (openBSD link)
• SIG30-C. Call only asynchronous-safe functions within signal handlers (openBSD link)
• SIG31-C. Do not access or modify shared objects in signal handlers (openBSD link)
• SIG32-C. Do not call longjmp() from inside a signal handler
• SIG33-C. Do not recursively invoke the raise() function
• ERR30-C. Set errno to zero before calling a function, and use it only after the function returns a value indicating failure
• MSC08-A. Library functions should validate their parameters
• POS36-C. Observe correct revocation order while relinquishing privileges

• FLP02 is missing a risk assessment
• ERR06 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.