Tags (Labels)

ROSE-Specific Tags (Labels)

Pages now have tags (also known as

{doc://display/DOC/Working with Labels Overview}Labels{doc}

) to indicate the status of their corresponding checker in Compass Rose:

At this point, all rules should have one of these tags. That is, they should be completely or partially checked by ROSE, or they should be marked 'rose-possible', in that we will try to check them with ROSE, or they should have one of the nonapplicable tags indicating we don't think they can be checked with ROSE

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
• 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.

...