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
In the same vein, I changed the incomplete java pages to use 'incomplete-java' tag. There are now exactly 3 incomplete rules. -svoboda
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.
is it this
comment? also, do you want this as a new rule, or integrated into [[ERR04-A. Choose an appropriate termination strategy]]?
yeah, that's the one. it's certainly related to [[ERR04-A. Choose an appropriate termination strategy]]. I'm not sure this is appropriate for there, however. It's not really an example of selecting an appropriate termination strategy, but avoid the consequences of using assert() or abort() in an program where the termination strategy is to exit(). I think a new recommendation, in the error section, with links to [[ERR04-A. Choose an appropriate termination strategy]] and the MISC Use assert recommendation, and cross referenced with labels to signal handling. -rCs
done. [[ERR06-A. Consider installing a SIGABRT handler when using assert() or abort()]]
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] 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.
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).
This needs to be checked again...
- 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.