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. We still need to remove the numbers for the severity, likelihood, and remediation costs from all the risk assessment tables.

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 INT11-A. Do not make assumptions about the layout of bit-field structures 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
• 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
• STR06-A. Do not assume that strtok() leaves the parse string unchanged
• 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.