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.
Move introductory material into their own sections.
per Ron Natalie comment on EXP32-C. Do not access a volatile object through a non-volatile reference, "What you need to do is either add a "DONT CAST AWAY VOLATILE" requirement or change the CONST cast rule to also say volatile."
Either approach is OK by me. - 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)
FIO43-C. Do not copy data from an unbounded source to a fixed-length array and STR35-C. Do not copy data from an unbounded source to a fixed-length array are the same rule, what's the deal? -alexv
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
- FIO09 is missing a risk assessment
- DCL31 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.