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.

...

It might also be worth giving these another look

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.

I moved the C++ pages to have their own incomplete-cpp tag since it looks to me like we are not focusing on them just yet. -alexv

Thanks, that will help. -rCs

I can't find his comment anymore, but I thought Doug Gwyn had a good suggestion for the error handling section about mixing using assert()). I think the recommendation was along the lines of

1. If you include calls to assert() at runtime
2. Or maybe just have other random calls to abort()
3. And you don't want the program to exit hard
4. You should consider writing a signal handler to catch SIGABRT to do any necessary cleanup.

Note that invoking a signal handler from abort() is a synchronous invocation, so you could actually call non-async functions provided you can block async invocation of the signal handler.

There seem to be several groups of rules/recs that very tightly interwoven, should we try to identify them and link them together using the label/navmap system a-la \[[FIO32-C. Do not perform operations on devices that are only appropriate for files]\]? \-alexv

went through and added a \[[tr24731|https://www.securecoding.cert.org/confluence/label/tr24731]\] tag to the appropriate pages since they are all somewhat related - alexv

The reference in INT13-A. Do not assume that a right shift operation is implemented as a logical or an arithmetic shift is really a side comment, so this rule is not really related so I removed the label. Haven't looked at the rest of these yet to see if they are legitimately related.

We can certainly reference other rules when it makes sense to do so.

Besides the cross references for each chapter, the only place I've used this is in the table for Automatically Generated Code.

I don't think we need a listing of all rules that contain a reference to TR 24731. Probably better to work this the other way around... if we need a table we can use the labels to create them. This is what we did for Automatically Generated Code.

Need to be careful when you have a new hammer that all problems don't start looking like nails.

I started this rule DCL31-C. Declare identifiers before using them but I would be OK with someone else finishing it. ;^)

I glommed several different things together... I think each needs to be considered separately, although it may be OK to maintain them all under this one rule.

added code samples that i think illustrate the point and a reference to DCL07 since it deals with a very similar problem - alexv 5/15 

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

A bunch of pages have screwed-up formatting, where some character, such as \[ (open-brace) is backslashed. This defeats its purposes of indicating a link. I've also seen this on open-braces. Someone needs to traverse the rules and clean these up. \-5/9 started cjohns (got as far as FIO05-A)

The Risk Assessment Summary tables for each section need to be updated (they are out of date with the actual rules). - I got as far as EXP07, which still has the risk assessment for EXP10

i went through on 4/15 and checked to make sure the section tables matched the rules... are we confident that the risk summaries in the rules are correct? -alexv 4/17 

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

...