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.
Run spider with new changes.
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.
References at the bottom of rules need a lot of work, here are some problem pages (based on broken/non-existent links)
- 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
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.