Pages that need work have an incomplete tag
Pages that need to be deleted have a deleteme tag.

Windows compliant solution went missing:

ENV00-A. Do not store the pointer to the string returned by getenv()

• reverted last edit to restore the solution, not sure how it got deleted - alexv 5/6 

MEM36-C. Do not store an address into an object with a longer lifetime says it is marked for deletion... does anything need to be done about this? should we move it to the void? -alexv 4/22

It needs a deleteme tag; we'll delete all the deleteme rules in due time -svoboda 5/2

The compliant solution for:

INT06-A. Use strtol() or a related function to convert a string token to an integer

needs to be rewritten to be compliant with ERR30-C.

The problem is that the value of errno is being checked without first ensuring that an error occurred.

According to C99:

The strtol, strtoll, strtoul, and strtoull functions return the converted value, if any. If no conversion could be performed, zero is returned. If the correct value
is outside the range of representable values, LONG_MIN, LONG_MAX, LLONG_MIN, LLONG_MAX, ULONG_MAX, or ULLONG_MAX is returned (according to the return type and sign of the value, if any), and the value of the macro ERANGE is stored in errno.

• According to the man page, the only time 0 is returned on error is when {{end_ptr == argv\[1\]}}, so I edited the solution to check for the three cases when {{errno}} can get set - alexv 5/6

The only reserved rule left is TMP31-C, which is awaiting decision from RCS. -pdc 5/1

TMP33-C and MEM36-C are marked for deletion... so they would become "reserved" once deleted... - alevx 5/6 

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/1 started cjohns (got as far as 06 Arrays)

Here is a rule that looks like it needs some work:

TMP30-C. Temporary files must be created with unique and unpredictable file names

Ok... I looked into this, and I think we can solve most of the problems with the TMP section by addressing the following -alexv 4/29

• integrate the concerns of TMP33-C. Temporary files must be removed before the program exits into TMP30-C. Temporary files must be created with unique and unpredictable file names by reiterating the need to clean up after temp files
  • done, but someone else should make sure they like the way I addressed this before deleting TMP33
  • then delete it as it is way redundant
• Be clear that there is no good solution for cleaning up after abnormal termination other than using a /tmp directory, but then that violates TMP00-A. Do not create temporary files in shared directories
  • There is a trade-off here... use a shared directory and worry more about security, or use a private directory and worry about cleanup
• We need more work on TMP00-A. Do not create temporary files in shared directories
  • Explain all the downsides to chroot jail (copying over DLLs, portability, how it is a HUGE mess, etc)
  • Demonstrate a good to way to create a private directory that is not as hard as a jail
  • Resolve the contradictions inherent between this rec and TMP33.. we say use }}{{{}{}{}{}{}{}{}{}tempnam in one, but say not to use }}{{{}{}{}{}{}{}{}{}tmpnam in another, moreover, our rule to use }}{{{}{}{}{}{}{}{}{}mkstemp or }}{{{}{}{}{}{}{}{}{}tmpfile_s contradicts TMP00 since neither guarantee a non-shared directory
    • use mkstemp and remember to clean up, then everyone is happy

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

In all rules, nullify free'd pointers. That is, add p = NULL; after instances of free(p);. Within reason of course...if p was local, and the next statement was return don't bother.

• i went through to try to implement this, and i'm finding that many of our code examples are ambiguous as to whether functions will end immediately following the last statement... would it be better to just always say p = NULL? regardless of whether or not we return? What about if the next operation is p = some_other_var? - alexv

Generally if the example code MAY do something else between the free() and return, it SHOULD have /* ... */. In which case you insert 'p = NULL' before the /* ... */. Code that MAY NOT do anything between the free() and return need no null-ification. Also, reassigning p to some other value immediately after a free also means you don't need p = NULL. The point here is to prevent p's old value from being re-used, esp. in code we don't control, and represent with /* ... */.

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

The list of sections in 00. Introduction do not match the order the pages go in via nav links. Is the list on 00Intro correct or is the nav order correct? -5/1 cjohns

Most likely the list order is correct. (IIRC the only cross-section nav links are from the last rule of a section to the first rule of the next section & back. -5/2 svoboda

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.