You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 262 Next »


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.


Functions have no parameters should be declared as void so as to document that this is intentional.

for example,

void abort(void);

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)


  • 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 (smile) 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.


  • No labels