{"text_format":"3","workbook":"xlsx","n_sheets":2,"sheets":["N1618-20120620","Categories"],"not_rendered":{"comments":1},"read":"whole","date_system":"1900"}

{"sheet":"N1618-20120620","index":0,"n_rows":167,"n_cols":10,"rows_kept":167}
["n","Comment #","Category (see the category tab)","Rule Code","Subsection","Page Number","Line Number","Comment and rationale","Proposed new text","Record of Response"]
["jb",1,"TL",null,"2.4.6","5",null,"The \"//\" followed by the '/' newline will not expand as expected and should be removed.  ","Remove the comment, or remove the empty if statement along with the comment, or change the algorithm to accommodate.","Comment removed."]
["jb",2,"E","accfree","5.2","10",null,"const char *argv[] is not Standard C, the const should be removed","Remove the const","const removed."]
["jb",3,"TL","funcdecl","5.15","27",null,"Return type from main() is not Standard C","Fix return type to EXIT_SUCCESS and/or EXIT_FAILURE","Return type changed to EXIT_SUCCESS."]
["jb",4,"TL","nullref","5.16","28",null,"The example is incorrect, the statement if (c_str) {  should be removed.","Remove the test of c_str and the braces associated with the statement.","Test removed."]
["jb",5,"TL","liberr","5.22","38",null,"The example is incorrect, the words and the example do not match.  ","Take the fseek() call out of the if statement, removing the test of the return value.","fseek() call removed from the if statement."]
["jb",6,"TL","libptr","5.23.4","41",null,"The words for example 1 do not seem to be correct and are inconsistent with the wording of the other examples in the documents.","In this noncompliant example, a diagnostic is required because the size parameter used in the memset() call was miscalculated.   The size of n has been calculated to be one longer than the size allocated for p. ","Change made."]
["jb",7,"TL","libptr","5.23.4","41",null,"The words for example 2 do not seem to be correct and are inconsistent with the wording of the other examples in the documents.","In this noncompliant example, a diagnostic is required because the size parameter used in the memset() call is possibly miscalculated.  There is no requirement that the size of an int is the same as the size of a float.","Change made."]
["jb",8,"TL","libptr","5.23.4","41",null,"The words for example 3 do not seem to be correct and are inconsistent with the wording of the other examples in the documents.","In this noncompliant example, a diagnostic is required because the size parameter used in the memcpy() call is possibly miscalculated.  The size of an int does not need to be smaller than that of a double.","Change made."]
["jb",9,"TL","libptr","5.23.4","42",null,"The words for example 4 do not seem to be correct and are inconsistent with the wording of the other examples in the documents.","In this noncompliant example, a diagnostic is required because, the value of n is not computed correctly allowing a possible write past the end ","Change made."]
["jb",10,"E","libptr","5.23.4","42",null,"In example code, the diagnostic required comment is on the wrong line.","Move the \"// diagnostic required\" comment to the line of code that includes the memcpy() function.","Comment moved."]
["jb",11,"TL","libptr","5.23.4","42",null,"The words for example 5 might be correct, but are convoluted and inconsistent with the wording of the other examples in the documents.","In this noncompliant example, a diagnostic is required because, the value of n that is used in the malloc() call has been possibly  miscalculated.  ","Change made."]
["jb",12,"TL","invptr","5.24.4","46 ",null,"pointer initialized by a call to malloc() is not checked before it is used.","Add a test to make sure s is not a null pointer.","Change made."]
["jb",13,"TL","dblfree","5.25.4","48",null,"In example 2, the call to free(), the parameter should be c_str1.","Change free(str1); to free(c_str1);","Change made."]
["jb",14,"TL","usrfmt","5.26","50",null,"fprintf(stderr, msg); is missing a specifier","Add specifier","Specifier added."]
["jb",15,"TL","ioileave","5.28",null,null,"In example, the parameters used in the fwrite() are incorrect.  It seems that parameter 2 and 3 are reversed.","Reverse the third and second parameters.  Or, better yet make the second parameter sizeof(char)","Third and second parameters reversed. Second parameter is now sizeof(char)."]
["jb",16,"TL","libmod","5.30","56",null,"char *locale is initialized by a call to setlocale() and later used without checking to make sure it is valid.","Add a test to make sure locale is a not NULL.","Test added."]
["jb",17,"E","resident","5.44","69","Ex 2","missing a  leading '_' in MY_HEADER_H","Add '_'","Added '_'"]
["jb",18,"TL","resident","5.44","70","Ex 6, 7","The snprintf call is malformed.","Fix parameters to snprintf","Parameters fixed."]
["JSM",1,"TL",null,"2.4.6","5","24-27","The “// retain LONG_MIN or LONG_MAX” comment, followed by a backslash-newline, will end up including the following line of code because backslash-newline processing applies before “//” comments are removed.  Since the “if” statement has empty body, and if the return type is narrower than long the intent of that comment may not be possible, removing the “if” seems a natural fix.","Remove the “if” statement checking against LONG_MIN and LONG_MAX, including its body and the comment.","Changed comment to /* */. If statement necessary for compliance with liberr."]
["JSM",2,"GT",null,"4.5","6","30-39","The concept of “derived type”, and the subsequent uses of it in various rules, is fundamentally confused.  It is trying to cover two different things: in the case of a subtraction expression (first bullet), it refers to integer expressions counting in units of the size of some type, but in the case of a sizeof expression (second bullet), it refers to integer expressions counting in bytes and counting the number of bytes in an object of a given type.  For [cntradd], it is correct to add expressions with the appropriate derived type (first sense) but incorrect to do so where they have that type in the second sense.  For [libptr], however, if copying arrays of int then a derived type (second sense) that is int is good, but a derived type (first sense) that is int is bad.  The definition and uses need fundamental reworking to deal with these two different senses.  They also need to ensure that “compatible” is properly used and certain cases such as “char” and “unsigned char”, “int” and “const int” or “int” and “int[10]”, where the types are incompatible by the ISO C definition, are not inappropriately disallowed.","In the absence of such a reworking, remove this definition and all uses of it.","Derived type and all references were eliminated."]
["JSM",3,"TL","divzero","5.17","28","25","INT_MIN / -1 and INT_MIN % -1, on two's complement implementations, have the same issue as divide-by-zero.","At end of first paragraph of 5.17, add “The same applies to INT_MIN / -1 and INT_MIN % -1 on two's complement implementations.”","Deleted rule."]
["JSM",4,"TL","swtchdflt","5.20","31","3","The rule is unclear about what constitutes logical incompleteness.  Note that variables of enum type may have any value of the compatible integer type, not just values of the enum constants.","Change the first paragraph to “A switch statement with a controlling expression of enumerated type that does not include a default case and does not include cases for all enumeration constants of that type shall be diagnosed because this indicates logical incompleteness.”.","Change made (did not include \"because this indicates logical incompleteness\")."]
["JSM",5,"TL","fileclose","5.21","31","26","It's fine not to deallocate all memory explicitly before exiting the program, or to close all input files explicitly likewise; letting the operating system clean things up is generally faster.","Add an Exception: “This does not apply if the last pointer to memory or an open file reaches the end of its lifetime on return from main.  In the case of a file open for writing, the program must still flush output with fflush and check for any resulting errors before return from main.","Retained rule as is."]
["JSM",6,"TL","liberr","5.22","32-38",null,"A reasonably style for writing to files is to check for errors once with ferror after a sequence of calls to output functions, rather than on every call.","Add an Exception: “A program may call ferror once to check for errors after a sequence of calls to output functions, rather than checking the return value of each call.”","Added NOTE: A cumulative error check satisfies the rule as long as undefined behavior is not triggered (for example, using the contents of the fgets or fgetws array or using the file position indicator after fread/fwrite without checking for error first). Did not add exception."]
["JSM",7,"TL","invptr","5.24","44","29","In Example 5, get_machine_name returns a pointer to the null character at the end of the string, which doesn't seem likely to be the intended semantics.","Insert “const char *p = machine_name;” after the check for NULL.  Use p instead of machine_name in the subsequent statements except for the return statement.","Change made."]
["JSM",8,"TH","restrict","5.33","59",null,"All the examples here are entirely valid in ISO C and should not be diagnosed.  memcpy copies array of characters of precisely the length given and the undefined behavior is if those two arrays overlap, not if they are both part of some larger object.  Example 1 copies between two consecutive nonoverlapping three-byte arrays and is entirely valid.  In example 2, the src operand is used twice to refer to unmodified memory, and that is allowed by C11 6.7.3.1; the aliasing restrictions only apply when the object is somehow modified.","Remove the whole rule; I don't think there's anything useful about “restrict” to diagnose as a security issue.  It may however be useful to diagnose arguments to memcpy that genuinely overlap.","The first example was modified so that the memory does indeed overlap. Changed the text of the second example to \"EXAMPLE 2 In this noncompliant example, the src operand is used twice to refer to unmodified memory, which is allowed by C11 6.7.3.1; the aliasing restrictions only apply when the object is modified. A diagnostic is required nonetheless because the pointer src is twice a restrict-qualified pointer parameter to dual_memcpy, referencing overlapping objects.\""]
["JSM",9,"TL","resident","5.44","70","15","MAX_SIZE is not an identifier reserved by stdint.h","Change MAX_SIZE to INT_BUF_MAX throughout.","Changed MAX_SIZE to SIZE_MAX."]
["JSM",10,"E","taintsink","5.46","72","3","“ Error! Reference source not found.” appears.\n","Replace with “restricted sink”.","Replaced."]
["WFW",1,"GE",null,"2","2-5",null,"Much of the text in the conformance section has nothing to do with conformance and should be moved from this section","See doc xxx where text from the conformance section is moved to th introduction. Note that it is also acceptable to move (parts of) this text to an informative annex.","Moved text from Conformance section to introduction."]
["WFW",2,"E",{"$nulls":4},"The document (sort of) defines notions like 'tained value' and 'tainted sink', but not the word 'taint' as a noun.","Suggest to replace the noun 'taint' everywhere with a construct where tainted is just as an adjective.","Added a definition of \"tainted source.\""]
["WFW",3,"TH",null,"2",null,null,"Explain what can conform and what not.","Add after the 1st paragraph in section 2 the following text: “Various types of programs (such as compilers or specialized analyzers) can be used to to check if the C source of a program contains any violations of the coding rules specified in this Technical Specification.  In this Technical Specification all such checking programs are called analyzers. An analyzer can claim conformity with this Technical Specification, programs (i.e., C sources) that do not yield any diagnostic when applied to a conforming analyzer cannot claim conformity to this Technical Specification.”","Added \"Various types of programs (such as compilers or specialized analyzers) can be used to check if a program contains any violation of the coding rules specified in this Technical Specification. In this Technical Specification all such checking programs are called analyzers. An analyzer can claim conformity with this Technical Specification. Programs that do not yield any diagnostic when analyzed by a conforming analyzer cannot claim conformity to this Technical Specification.\""]
["WFW",4,"TH",null,"2",null,null,"An analyzer should not be bothered with checking conformity with the C standard, hence an analyzer must be allowed to assume that its input is strictly conforming C.","In paragraph 3 of section 2 replace “program” by “strictly conforming C program”.","Analyzers must be able to analyze conforming programs as well as strictly conforming programs. Did not use \"strictly conforming.\""]
["WFW",5,"GE",null,"2","1st note",null,"Should a diagnostic be required to identify the rule by its identifier? If not then the identifiers are are not explained or used anywhere and they should be removed from all rules. If the identifiers are to be maintained then they should be introduced (in the scope section?) and be used in the diagnostic.",null,"Added the following text to the introduction following \"secure coding rules (clause 5)\": Each secure coding rule in clause 5 has a separate numbered subsection and a unique section identifier enclosed in brackets (e.g., [ptrcomp]). The unique section identifiers are mainly for use in identifying the rules, in case the section numbers change because of the addition or elimination of a rule.  These identifiers may be used in diagnostics issued by conforming analyzers, but analyzers are not required to do so. "]
["WFW",6,"GE",null,"2","Paragraph after 1st note",null,"It is unclear what this paragraph is requiring. In the 1st sentence the key seems to be “in the whole program” but what does that add? The 2nd sentence is not needed at all.","Strike this paragraph, move the subsequent note after the 3rd paragraph of this note (see WFW-4).","Removed paragraph.  Added the following text to the introduction: This Technical Specification assumes that an analyzer's visibility extends beyond the boundaries of the current function or translation unit being analyzed."]
["WFW",7,"TL",null,"2.2",null,null,"Portability assumptions, 1st sentence: a conforming analyzer shall be generic, not work for just one implementation.","Strike sentence","The consensus of the study group (known as the \"San Francisco rule\") is that an analyzer need only work for one implementation. This allows, for example, an analyzer that only works with one specific compiler to be considered conforming."]
["WFW",8,"TL",null,"2.2",null,null,"Reformulate portability assumptions to include implementation-defined aspects","The rules in this Technical Specification are formulated in the most general form, but the security aspects of a rule may depend on  actual implementation-defined aspects of the target platform (examples are the sizes of the various integer types and the signedness of the type char).  A conforming analyzer may be informed (in an analyzer implementation-defined way) about the C language implementation-defined aspects of the target platform that may have effect on the applicability of a rule; in such a case an conforming analyzer need not to report on those rules that do not create a security risk for this particular target platform.","This is also covered under the San Francisco rule, specifically: An analyzer need not diagnose a rule violation if the result is documented for the target implementation and does not cause a security flaw."]
["WFW",9,"TL",null,"3",null,null,"The list of normative references is far too large; unless they are explicitly referred to in this TS normative references from e.g. the C standard need not to be repeated here. What is the use of  the reference to IEC 61508?","Reassess all current entries and where possible remove unnecessary entries.","Reduced to: [ISO/IEC 9899:2011] Programming Languages—C.\n[ISO 31-11:1992] Quantities and units—Part 11: Mathematical signs and symbols for use in the physical sciences and technology.\n[ISO/IEC 2382-1:1993] Information technology—Vocabulary—Part 1: Fundamental terms.\n[ISO/IEC/IEEE 9945:2009] Information technology—Portable Operating System Interface (POSIX®) Base Specifications, Issue 7.\n"]
["WFW",10,"TL",null,"4.7",null,null,"The definition of restricted sink is different from (and much vaguer than) the description in 2.4.2. According to the definition here, a sanitized (previously) tainted value cannot flow into a restricted sink which contradicts Note 2.","Reformulate.","Reformulated definition as follows: restricted sink\noperands and arguments whose domain is a subset of the domain described by their types\nNOTE 1 Undefined or unexpected behavior may occur if a tainted value is supplied as a value to a restricted sink.\nNOTE 2 A diagnostic is required if a tainted value is supplied to a restricted sink.\nNOTE 3 Different restricted sinks may impose different validity constraints for the same value; a given value can be tainted with respect to one restricted sink but sanitized (and consequently no longer tainted) with respect to a different restricted sink.\nNOTE 4 Specific restricted sinks and requirements for sanitizing tainted values are described in specific rules dealing with taint analysis (see 5.8, 5.14, 5.23, 5.29, 5.38, and 5.45).\n"]
["WFW",11,"TL",null,"4.15",null,null,"Tainted value is defined using the notion 'tainted data' which is not defined. What makes data 'tainted data'?","Reformulate.","Redefined terms."]
["WFW",12,"GE",null,"5",null,null,"Each subsection in the rules section is unstructured and contains too much noise: one has to really search for the actual rule. Take section 5.1: the rule is (probably) the sentence just before the example but that is in no way clear. ","Use a 'standard' lay-out for each rule subsection with subheadings like 'Rule', 'Rationale', 'Example'. Move the list of related guidelines to an annex.","Added Rule and Rationale sections to each rule."]
["DEW",1,"TL",null,null,"vii","Paragraph 8","Paragraph 8, second sentence refers to this document as a standard, when it is a technical specification.","Replace:\nA bibliography lists documents that were referred to during the preparation of the standard.\nwith:\nA bibliography lists documents that were referred to during the preparation of this technical specification.","Change made."]
["DEW",2,"TL",null,null,"vii","Paragraph 9","Paragraph 9 beginning: The rules documented in this Technical Specification rely only on non-annotated source files ...\n\nDon’t see how this is relevant.  Appears to be text meant to appease some kind of disagreement between its authors, but adds nothing to the requirements of the specification.\n","Remove paragraph 9","Changed to: \"The rules documented in this Technical Specification do not rely on source code annotations or assumptions of programmer intent.\""]
["DEW",3,"TH",null,"2","1 & 2","Paragraphs 3 & 4","Section 2, Paragraphs 3 and 4 seem to conflict with each other.  Paragraph 3:\nA conforming analyzer shall issue at least one diagnostic for a program containing one or more violations of\nthe rules in this specification.\nParagraph 4:\nFor each distinct rule in this Technical Specification, a conforming analyzer shall be capable of producing a\ndistinct diagnostic.","Remove paragraph 3","Changed to:\n\"For each distinct rule in the Technical Specification, a conforming analyzer shall be capable of producing a diagnostic upon encountering a violation of that rule in isolation. \n   In the case that the same program text violates multiple rules simultaneously, a conforming analyzer may aggregate diagnostics, but shall produce at least one diagnostic.\"\n "]
["DEW",4,"TL",null,"2","2",null,"Section 2, Paragraph 6:\nConformance is evaluated by testing the ability of analyzers to diagnose all violations of the rules represented by the noncompliant examples and not diagnose compliant examples and exceptions in the whole program.\n\nThis sentence does not help define conformance.  It appears to be defining how to verify conformance.\n","Remove the sentence.","Paragraph modified and moved."]
["DEW",5,"TH",null,"2.1","2 & 3",null,"Except for paragraph 2, this section seems to be talking about the quality of implementations as opposed to helping specify secure c coding rules.","Remove content of section 2.1, except paragraph 2:\nThe analyzer shall report a diagnostic for at least one program that contains a violation of each rule.","Contents of section 2.1, except this sentence, have been moved to the introduction."]
["DEW",6,"TH",null,"2.4.2","4",null,"What is a “taintededness sink” ?\nCertain parameters of certain library functions are restricted sinks because these functions ... pass these parameters on to another taintededness sink. ","My guess is that “taintededness sink” was suppose to be “restricted sink”, in which case this would be editorial.","Changed \"taintednes sink\" to \"restricted sink\""]
["DEW",7,"TL",null,"2.4.4","4",null,"Only the first sentence contributes to defining secure C coding rules.  The rest seems to be noting implementation issues.\nIf this is to be kept, I’d suggest making it a note.","By definition, any tainted value flowing into a restricted sink is a security issue, so all such cases must be diagnosed. \n\nNote: Diagnosing these violations requires some form of data flow analysis. In its most basic form, such an analysis operates intraprocedurally to determine which local tainted sources flow into local restricted sinks. Intraprocedural analysis is limited and can be extended by interprocedural analysis. Interprocedural analysis can be accomplished by top-down or bottom-up approaches that follow global data flow more than they follow the call graph. For example, in a bottom-up analysis, the parameters identified in the first step as flowing into restricted sinks would themselves be treated as restricted sinks at all of their function’s call sites, recursively. In addition, function return values can be identified as tainted sources and treated accordingly at each call site. This description ignores such details as recursion and programs such as libraries with multiple call graph roots. It also ignores the large issue of tainted data escaping into the heap or into global or static variables.","Section removed."]
["DEW",8,"TL",null,"2.4.5","4",null,"Paragraph 2 appears to be a discussion of implementation as opposed to defining secure C coding rules.","Designate paragraph as a “NOTE:”","Retained paragraph."]
["DEW",9,"E",null,"4.2","6",null,"Change “signal handler context” to “signal handler” as 7.14.1.1 of ISO/IEC 9899:2011 defines a signal handler thusly:\nAn invocation of such a function because of a signal, or (recursively) of any further functions called by that invocation (other than functions in the standard library),251) is called a signal handler.","Change “... signal handler context” to “... signal handler”","Change made."]
["DEW",10,"E",null,"4.15","8",null,"Make the definition of tainted value consistent with 2.4.1    Taint and tainted sources","Change “untrusted tainted data” to “tainted source”","Change made."]
["DEW",11,"TL",null,"4.20","8",null,"This seems inconsistent with 2.4.1 Taint and tainted sources.  What is “untrusted source”?\nHowever, if we accept the proposed new text, then what is the difference between 4.15 tainted value and 4.20 untrusted data?","Change ‘untrusted source” to “tainted source”","Changed to \"from outside a trust boundary\""]
["DEW",12,"TL",null,"4.4","6",null,"I can find no references to the definition of “dereferenceable pointer” in the specification.  Dereferencable pointer is defined in terms of a valid pointer, AFAICT the definitions of dereferenceable pointer and valid pointer are identical.","Remove all of 4.4 dereferenceable pointer, and renumber.","Removed and renumbered."]
["DEW",13,"TL",null,"4.2","6",null,"I can find no references to the definition of a “asynchronous-safe function”.  The words only appear in the title of a reference to the Cert C Secure Coding Standard.","Remove all of 4.2 and renumber.","Removed and renumbered."]
["DEW",14,"TL","accfree","5.2","10/11",null,"Regarding example 3.  The C standard seems to be pretty clear, realloc may NOT free c_str1 when it returns NULL. DR 400 is addressing the issue, and may change that.","Remove example 3.","Pending resolution of DR#400. The discussion in Kona was to allow this behavior in a conforming implementation. Added a note to remove thisexampe if WG14 goes in a different direction."]
["DEW",15,"E",null,"1","1",null,"Add an explanation of the UB section/table found in each rule.","Each rule in this document that is based on undefined behavior defined in the C standard identifies the undefined behavior by a numeric codes.  The numeric codes for each undefined behavior can be found in annex B, Undefined Behavior.","Explanation added."]
["DEW",16,"TH","cntradd","5.4","13",null,"For the other C Secure Coding rules the examples text explain how they are violating the rule for which they are an example.  However for cntradd the examples leave it to the reader to figure out.  I would find it really useful if the example text is defined using the terminology of the rule.  I've suggested changes for these examples intended to be of the same style as examples in other rules which explain how the rule is violated.\n\nExample 3 says:  In this noncompliant example, a diagnostic is required because the byte count integer skip is added to the element pointer s.\n\nExactly how does Example 3 violate the cntradd rule?  Let’s explain it in the lead-in text.\n\nAll 4 examples of cntradd rule suffer from this issue.","What I think example 3 should say:\nIn this noncompliant example, a diagnostic is required because the derived type of skip (an unspecified char type) is incompatible with the derived type of sizeof(struct big)(struct big).\n\nOr maybe the following wording to be both informal and explicit:\n\nIn this noncompliant example, a diagnostic is required because the byte count integer skip is added to the element pointer s, i.e. the derived type of skip (unspecified character type compatible with any of char, signed char, and unsigned char) is incompatible with the derived type of sizeof(struct big)(the type struct big).\n\n====================\nSuggested rewording of Example 1 lead in:\nIn this noncompliant example, a diagnostic is required because the derived type of sizeof(buf) (array of long) is incompatible with the type of the pointer buf_ptr (long) to which it is added.\n\nSuggested rewording of Example 2 lead in:\nIn this noncompliant example, a diagnostic is required because the\ndifference of two pointers is divided by an integer sizeof(struct s) whose derived\ntype, struct s, is incompatible with that of the pointers, struct s *.\n\nSuggested rewording of Example 4 lead in:\nIn this noncompliant example, a diagnostic is required because the derived type of the integer expression wcslen(error_msg) * sizeof(wchar_t), an unspecified character type compatible with any of char, signed char, and unsigned char, is incompatible with the type pointed to by the pointer error_msg, wchar_t, to which it is added.\n","Rule deleted."]
["DEW",17,"TH",null,"4.9","7",null,"This is describing behavior beyond that defined by the C standard.","Remove 4.9 and renumber","Deleted definition of persistent signal handler"]
["DEW",18,"TH","sigcall","5.8","20",null,"This is describing behavior beyond that defined by the C standard.","Remove 5.8 and renumber","Retained rule."]
["DEW",19,"TL","funcaddr","5.10","22",null,"Add a definition of “thrd_current” to example 1 and example 2 so it is at least obvious it is a function pointer.","Add following to example 1 and example 2:\nvoid thrd_current(void);","Rule deleted."]
["DEW",20,"TL","intptrconv","5.12","24",null,"More explanation is needed in example 1 as to why the following line requires a diagnostic:\nunsigned int number = (unsigned int)ptr; // diagnostic required","The lead in to the example, might explain that on an implementation where pointers are 64-bits and unsigned integers are 32 bits, a diagnostic is required for:\nunsigned int number = (unsigned int)ptr; // diagnostic required","Changed to: \"EXAMPLE 1 In this noncompliant example, a diagnostic is required on an implementation where pointers are 64-bits and unsigned integers are 32 bits because the pointer ptr is converted to an integer.\" Simplified Example 1 to only include one rule violation"]
["DEW",21,"TL","intptrconv","5.12","24",null,"More explanation is needed in example 1 as to why the following line requires a diagnostic:\nnumber = (number & 0x7fffff) | (flag << 23);\n} ptr = (char *)number; // diagnostic required\n\nintptrconv defines the rule:\nConverting an integer type to a pointer type shall be diagnosed if the resulting pointer is incorrectly aligned, does not point to an entity of the referenced type, or is a trap representation.\n","Change “the integer number is converted to a pointer” to “the integer number is converted to a pointer because it does not point to an object of the referenced type.”\n\nSee example 1 of 5.13 for a well formatted example explaining the rule violation.","Changed to: \"EXAMPLE 1 In this noncompliant example, a diagnostic is required on an implementation where pointers are 64-bits and unsigned integers are 32 bits because the pointer ptr is converted to an integer.\" Simplified Example 1 to only include one rule violation"]
["DEW",22,"TL","filecpy","5.14","25",null,"What does this text mean?\n“Copying a FILE object shall be diagnosed because the copy does not need to be safe to be used as an argument to any I/O function.”\nThe following reference to 7.12.3 paragraph 6 explains the issue.","Replace “Copying a FILE object shall be diagnosed because the copy does not need to be safe to be used as an argument to any I/O function.” with “Copying a FILE object shall be diagnosed.”","Change made."]
["DEW",23,"TH","funcdecl","5.15","26",null,"5.2.4.1 Translation limits\ndefines the limit on external identifiers as being:\n31 significant initial characters in an external identifier","In example 4, change 2 occurrences of “bash_groupname_completion_func” to “bash_groupname_completion_funct”","Changes made."]
["DEW",24,"E","divzero","5.17","28",null,"Missing UB reference","Add a UB table like the other rules with a reference to:\n45    The value of the second operand of the / or % operator is zero (6.5.5).","Rule deleted."]
["DEW",25,"E","liberr","5.22","32",null,"Missing UB reference(s)\nThe rule says “Failure to branch conditionally on detection or absence of a standard library error condition shall be diagnosed because this can result in undefined or unexpected behavior.”  But the rule is missing the UB table like other rules that refer to undefined behavior.","Not sure which UB to refer to ...","Undefined behavior in this case refers to any downstream undefined behavior. Undefined behavior has been deleted in this context."]
["DEW",26,"E","libptr","5.23","39",null,"Use consistent style for referencing UB.  Other rules use a two column table labeled UB with the a row for each or only UB involved.  See 5.6, 5.7, 5.15 for examples.","Replace:\n (see item 109 in Annex B)\nwith: a table labeled UB with a row of two columns, UB | The pointer passed to a library function array parameter does not have a value such that all address computations and object accesses are valid (7.1.4).","Change made."]
["DEW",27,"TL","libptr","5.23.4","41",null,"A rule is being defined in a note:\nNOTE For purpose of this rule, the term size refers, for a declared object, to the size of the object, and for an allocated object, to the amount of the allocated storage. For a function f taking the pair of not necessarily consecutive arguments (p, n), where p is a non-const-qualified (possibly void *) pointer and n is an integer that specifies the size of the object referenced by p, a call to f where n is greater than the number of remaining bytes in the object referenced by p shall be diagnosed.","Move the second sentence of this note into a standalone paragraph following the note, i.e.:\nNOTE For purpose of this rule, the term size refers, for a declared object, to the size of the object, and for an allocated object, to the amount of the allocated storage. \n\nFor a function f taking the pair of not necessarily consecutive arguments (p, n), where p is a non-const-qualified (possibly void *) pointer and n is an integer that specifies the size of the object referenced by p, a call to f where n is greater than the number of remaining bytes in the object referenced by p shall be diagnosed.\n\nAlternatively, maybe this rule should become it’s own subsection 5.23.5, as three of the 5 examples following the paragraph that demonstrate the application of this rule do not even use the functions listed in 5.23.4.","Broke out the note from the normative text."]
["DEW",28,"TH","dblfree","5.25","47/48",null,"This rule uses a reference [Seacord 2005], instead of referencing the UB upon which it based.  \n\nThis rule has a parenthetical “(subject to the following exception)”.  None of the rules that proceed it have this  or a similar parenthetical.  Those rules simply state the rule, then have “Exception” paragraphs as needed.","Replace:\nFreeing memory multiple times shall be diagnosed (subject to the following exception) because this results in “double-free” vulnerabilities [Seacord 2005].\n\nwith:\n\nFreeing memory multiple times shall be diagnosed because this results in “double-free” vulnerabilities.\nfollowed by the usual UB table as in other rules with this entry:\nUB   |   Description\n------+--------\n179   |  The pointer argument to the free or realloc function does not match a pointer earlier returned by a memory management function, or the space has been deallocated by a call to free or realloc (7.22.3.3, 7.22.3.5).","Change made."]
["DEW",29,"TH","inverno","5.27.1","51",null,"Need a definition of the term “in-band error indicator”.  It is not obvious.","Either to section 4 Terms and Definitions add the following definition (I don’t know if this is a correct definition, thus the request for a definition), or provide the definition of in-band error indictor in 5.27.1:\nIn-band error indicator\nA library function return value on error that is also a valid return value for successful calls to that library function.","Added definition of \"in-band error indicator.\""]
["DEW",30,"TH","inverno","5.27.2","51",null,"Need a definition of the term “out-of-band error indicator”.  It is not obvious.","Either to section 4 Terms and Definitions add the following definition (I don’t know if this is a correct definition, thus the request for a definition), or provide the definition of out-of-band error indictor in 5.27.2:\nA library function return value on error that can never be returned by a successful call to that library function.","Added definition of \"out-of-band error indicator.\""]
["DEW",31,"TL","inverno","5.27.4","53",null,"Clarification of example 3","Change the lead-in sentence in part to read “... function setlocale because setlocale does not explicitly set errno.”","Change made."]
["DEW",32,"E","ioileave","5.28","54",null,"Can we please have the same formatting and editorial style as the preceding rules.","Replace:\nAccording to C, section 7.21.5.3, paragraph 7,\n\nWhen a file is opened with update mode . . ., both input and output may be performed on the associated stream. However, output shall not be directly followed by input without an intervening call to the fflush function or to a file positioning function (fseek, fsetpos, or rewind), and input shall not be directly followed by output without an intervening call to a file positioning function, unless the input operation encounters end-of-file. Opening (or creating) a text file with update mode may instead open (or create) a binary stream in some implementations.\n\n(See also undefined behavior 151, Annex B.)\n\nwith:\n\nUB   |   Description\n------+--------\n151   |  An output operation on an update stream is followed by an input operation without an intervening call to the fflush function or a file positioning function, or an input operation on an update stream is followed by an output operation with an intervening call to a file positioning function (7.21.5.3).","Change made."]
["DEW",33,"TL","intoflow","5.31","57",null,"Why does Example 1 apply to implementations that trap on signed integer overflow instead of all implementations.","Change in part: “... is required on implementations that trap on signed integer\noverflow because...” to “... is required because ...”.","Rule changed to state that :  Whenever at least one operand is tainted, signed integer operations that trap and that can overflow shall be diagnosed."]
["DEW",34,"TL","xfree","5.34","60",null,"Missing UB reference","After the rule and before Example 1 add:\nUB   |   Description\n------+--------\n179   |  The pointer argument to the free or realloc function does not match a pointer earlier returned by a memory management function, or the space has been deallocated by a call to free or realloc (7.22.3.3, 7.22.3.5).","UB table added."]
["DEW",35,"TH","xfree","5.34","60",null,"The exception is talking about behavior beyond that defined in the standard.  The proposed exception does not aid in making the code more portable.","Remove the Exception.","Retained exception text. The exception is an explicit statement of what would be implicitly true anyway. Behavior that does not cause an error on a particular implementation does not need to be diagnosed. The specific behavior excepted is permitted by the standard."]
["DEW",36,"TL","uninitref","5.35","61",null,"The rule refers to undefined behavior without specifying which UB.  I’m not sure if it is UB 12 or both UB 11 and 12.","After the paragraph that defines the rule to be diagnosed, which starts with “Uninitialized memory ...”, add:\nUB   |   Description\n------+--------\n11    | The value of an object with automatic storage duration is used while it is indeterminate (6.2.4, 6.7.9, 6.8).\n12    | A trap representation is read by an lvalue expression that does not have character type (6.2.6.1).","Changes made."]
["DEW",37,"E","ptrobj","5.36","63",null,"Unnecessary use of “(subject to the following exceptions)” in the rule.  Most of the rules that proceed it do not have this  or a similar parenthetical.  Those rules simply state the rule, then have “Exception” paragraphs as needed.  Part of comment #28 has the same issue.  Trying to keep the editing style consistent.","Remove the parenthetical “(subject to the following exceptions)”.","Change made."]
["DEW",38,"E","taintformatio","5.40","65",null,"Restating a concept defined in a previous section.  Either remove it or turn it into a cross reference.","Remove the paragraph “A tainted value is one that originates from a tainted source, as defined in Section 2.4.1.”, or replace it with a cross reference:\n(See 2.4.1 Taint and tainted sources)","Removed restated concept."]
["DEW",39,"TL","xfilepos","5.41","66",null,"Add a reference to the appropriate UB","After the paragraph that defines the rule to be diagnosed, add:\nUB   |   Description\n------+--------\n175    | The fsetpos function is called to set a position that was not returned by a previous successful call to the fgetpos function on a stream associated with the same file (7.21.9.3).","UB table added."]
["DEW",40,"E","resident","5.44","69",null,"Use consistent style for referencing UB.  Other rules use a two column table labeled UB with the a row for each or only UB involved.  See 5.6, 5.7, 5.15 for examples.","Remove “See also undefined behavior 106 of Annex B.”.  And then after the same paragraph add:\nUB   |   Description\n------+--------\n106    | The program declares or defines a reserved identifier, other than as allowed by 7.1.4 (7.1.3).","UB table added."]
["DEW",41,"E","invfmtstr","5.45","71",null,"Missing UB reference(s)\n","Add a UB | Description table with these UB values: 155, 156, 157, 158, 159, 160, 161, 162","UB table added."]
["DEW",42,"E","taintsink","5.46","72",null,"Fix the indicated document error","Remove the text “ Error! Reference source not found.”","Fixed."]
["DEW",43,"E","ptrcomp","5.1","9",null,"Use consistent style for referencing UB.  Other rules use a two column table labeled UB with the a row for each or only UB involved.  See 5.6, 5.7, 5.15 for examples.","Remove “(see undefined behavior 37 in Annex B)”.  And then after the same paragraph add:\nUB   |   Description\n------+--------\n37    | An object has its stored value accessed other than by an lvalue of an allowable type (6.5).","UB table added."]
["JWT",1,"E",null,"2.4.2","4",null,"typo \"taintededness\"","Replace with \"tainted\".","Replaced with \"restricted sink\"."]
["JWT",2,"E",null,"3","5",null," There's a reference to floating-point standard IEC 60559:2011, though C11 is based on the older 60559:1989.","Change reference to \"[IEC 60559:1989] Information technology-Microprocessor systems-Binary floating-point arithmetic\".","Change made."]
["JWT",3,"E","divzero","5.17","28",null,"Refers to \"dividing by zero\" without qualification as pertaining to integer types. (Floating-point exceptions are not covered in this document.)","Change title to \"Integer division by zero\"","Renamed to \"5.25 Integer division errors [diverr]\" because of the expansion to include unrepresentable quotients.  "]
["JWT",4,"E","dblfree","5.25","47",null,"Relies on reference to [Secord 2005] for  explanation of \"double-free\" vulnerabilities.","Provide a brief explanation, in addition to the reference.","Referenced undefined behavior instead of [Seacord 2005]."]
["JWT",5,"E",null,"5.27.1","51",null,"Are terms in-band and out-of-band well known?","If not, avoid the terms and just say what they mean, or provide the definitions.","Added definition for both in-band and out-of-band error indicator"]
["JWT",6,"TL",null,"5.27.2","51",null,"If an error indicator is returned, the program must check errno, but the program is not required to clear errno before calling the function.","Something like: \"A program that uses errno for error checking need not in all cases set errno to zero before calling one of these library functions. If and only if the function returned an error indicator, the program shall have cleared errno before the function call and shall inspect errno before a subsequent library function call.\"","Changed to:  A program that uses errno for error checking need not set errno to zero before calling one of these library functions. If and only if the function returned an error indicator, the program shall clear errno before the function call and shall inspect errno before a subsequent library function call."]
["JWT",7,"E",null,"5.27.3","52",null,"The specification requires a diagnostic for these functions only where errno is checked when it shouldn't be, not where it's not check when it could be. Is this as intended?","If \"yes\", no change required.","Yes, that is correct.  Other rules, such as Failing to detect and handle standard library errors [liberr], require specific errors to be checked."]
["JWT",8,"E",null,"5.46","72",null,"Shows \"Error! Reference source not found\".","Fix link.","Fixed."]
["RCS",1,"TL",null,"5",null,null,"Missing rule for non-null terminated strings","Add proposed text from the 13-Mar-12 teleconference of the CSGR study group.","Rule added: 5.30 5 Passing a non-null-terminated string to a library function [nonnullstr]"]
["RRB",1,"E (Q)",null,"2","2","5","The examples are not complete programs. For example, there can be \"#define free \" for the double free rule.","Conformance is evaluated by testing the ability of analyzers to diagnose all violations of rules represented by the noncompliant examples and not diagnose compliant examples and exceptions in the whole program. -> Conformance is evaluated by testing the ability of analyzers to diagnose all violations of rules represented by minimal complete programs that contain the noncompliant examples and not diagnose minimal complete programs with compliant examples and exceptions.","The response to another comment fixed this in a different way."]
["RRB",2,"E",null,"2.4.6","5",null,"Why is the \"do ... while (0)\" loop present?","Remove the \"do\" and \"while\" parts.","This is done to make the macro usable as the body of an if statement."]
["RRB",3,"E",null,"4.6","7",null,"Why explicitly spell out software? Can be hardware, firmware, etc. I'm assuming it is because this is software static analysis, but want to be sure.",null,"Deleted software."]
["RRB",4,"TL",null,"4.11","8","3","The example is not a sanitization example. Make the example say adding the null if there is not one present in the first x characters?","EXAMPLE Adding a null character to the end of a buffer before passing a string to strlen.","Done."]
["RRB",5,"E (Q)",null,"4.12","8","1","Why explicitly spell out software? Can be hardware, firmware, etc. I'm assuming it is because this is software static analysis, but want to be sure.",null,"Deleted software."]
["RRB",6,"TL","accsig","5.3","11","Paragraph 2","It seems the text for the undefined behaviour was copied from the previous rule.","... as a result of accessing freed memory: -> ... as a result of accessing a static storage duration object without the correct characteristics:","Done."]
["RRB",7,"GE","accsig","5.3","11",null,"EXIT_SUCCESS not defined (since it has a main, assuming it is a full program). Applies to other rule examples as well.","Add in to the beginning of the source code: \"#define EXIT_SUCCESS 0\"","This is defined in stdlib.h.  The appropriate standard headers are assumed to be included, for brevity. No change made."]
["RRB",8,"GE","cntradd","5.4","12, 14",null,"Example 1,4: BUFSIZ is not always meaningful as it can be interpreted in more than one way (applies to other short formed name examples as well)","Change BUFSIZ to BUFFER_SIZE","Rule deleted by response to another comment."]
["RRB",9,"E","cntradd","5.4","12",null,"The two buffers are for different purposes. They should have different size specifiers.","Change BUFSIZ in the collect_longs() function to BUFSIZE2 or better yet BUFFER_SIZE2","Rule deleted by response to another comment."]
["RRB",10,"GE","cntradd","5.4","12",null,"Most examples have () as the function argument lists. This is usually poor programming practice.","Change () function argument lists to (void). Ex. Change collect_longs() to collect_longs(void) in example 1","Done wherever appropriate."]
["RRB",11,"TL","boolasgn","5.5","14",null,"Ternary operator second+third says any of these contexts, but what are \"these contexts\"? If it is the entire list above it, then it is already diagnosed, so nothing special for the second or third operands.","Remove the \"where that operand …\"","Changed to state: • comma operator (second operand) when the comma expression is used in any of these contexts\n• ?: (second or third operands) where the ternary expression is used in any of these contexts\n  "]
["RRB",12,"E","boolasgn","5.5","15",null,"All the examples have empy block bodies which may be interpreted to have some (no) meaning.","Put in /* ... */ in all the block bodies.","Done."]
["RRB",13,"E","boolasgn","5.5","15",null,"In exception 1, comparison expression is not defined.","Add in a definition to comparison expression Ex. \"op1 == op2 or op1 != op2\"","Done."]
["RRB",14,"TL","boolasgn","5.5","15",null,"In exception 2, example 2 a comparison operator is listed but not a relational operator.","Change \"not a comparison operator\" to \"not a comparison or relational operator\"","Done."]
["RRB",15,"E (Q)","boolasgn","5.5","15",null,"In exception 2, why is primary expression allowed but not the case in exception 2, example 2, as it seems to be a common paradigm as well. Related, it could be (x = y) && (z = w) which would also not be allowed but seems to be common.",null,"This is because the primary expression is not the entire expression."]
["RRB",16,"TL","asyncsig","5.6","16",null,"It seems the text for the undefined behaviour was copied from a previous rule.","Paragraph 2: Change \"... as a result of accessing freed memory\" to \"... as a result of calling other C library functions:\"","Done."]
["RRB",17,"E","asyncsig","5.6","16",null,"See comment 10.","Example 1: Change \"log_message()\" to \"log_message(void)\"","Done."]
["RRB",18,"E","asyncsig","5.6","16",null,"Is it intended that there be no actual signal or raise given this looks like a complete program.","Add in a comment in the main loop body as follows: \"/* An interactive attention signal may happen here */\"","Done. Added /* An interactive attention signal might invoke handler() from here on. */"]
["RRB",19,"E","argcomp","5.7","19",null,"Examples 2,3,4: The comments to separate source files can be ignored implying a single file. Use some other mechanism to distinguish separate files.","Use \"--- File 1 ---\" and \"--- End File 1 ---\" as the file separators.","This is a style decision throughout the document.  We believe this is clear as is."]
["RRB",20,"E (Q)","funcaddr","5.10","22",null,"What is the vulnerability? If it is just programming error, there are a lot more that can be added than this. Need to add in an example of a vulnerability.",null,"Rule has been eliminated."]
["RRB",21,"TL","alignconv","5.13","24",null,"There may be no type the pointer points to. For example, if there was a \"c_ptr++;\" in example 2 between the pointer assignments.","Change \"the type the value actually points to shall\" to \"the type the value actually points to, if any, shall\"","The \"points to\" relates to its type. Not changed."]
["RRB",22,"TL","filecpy","5.14","25",null,"Need to indicate that FILE is the C Standard FILE object.","Example 1: Add \"#include <stdio.h>\" at the start of the source or state in the example preamble that FILE is the standard library FILE object.","This is assumed for brevity throughout the document."]
["RRB",23,"E","funcdecl","5.15","27",null,"There is no aliasing example.","Add in an aliasing example. Ex.\n--- File 1 ---\nint getRC(int *code) {\n  return *code;\n}\n--- End File 1 ---\n\n--- File 2 ---\nint getRC();\n\nint main(void) {\n  long errors = 0;\n  \n  /* ... */\n  \n  return getRC(&errors);  // Diagnostic required\n}\n--- End File 2 ---\n","This violates a different rule, [argcomp]."]
["RRB",24,"TL","nullref","5.16","28",null,"In the example, doesn't the \"if (c_str)\" check guarentee that c_str is not null? If this is intended for the input_str pointer then the entire example description has to change.","Remove the null check.","Done."]
["RRB",25,"TL","liberr","5.22","38",null,"In the example, the \"if\" statement is an implicit check yet the description says no check of the return value.","Remove the \"if\" statement, but keep the condition as an expression.","Done."]
["RRB",26,"E","libptr","5.23.2","40",null,"In the last paragraph size is both a parameter and a term. Should disambiguate them for clarity.","Change \"of at least size bytes\" to something like \"of at least x bytes, where x is given by the size argument\"","Changed to : The following standard library functions take two pointer arguments and a size argument, with the constraint that both pointers must point to valid memory objects of at least the number of bytes or wide characters as appropriate, indicated by the size argument."]
["RRB",27,"TL","invptr","5.24","43",null,"A runtime check is described instead of a static analysis check.","In example 1, change \"required if f is called\" to \"required since f can be called\" (goes from being a runtime check to a static analysis time check) or add in \"because\" in front of the \"if\" as in the other examples.","Changed to:  EXAMPLE 1 In this noncompliant example, a diagnostic is required because if f is called with a negative argument for index, an out-of-bounds pointer is formed."]
["RRB",28,"E","invptr","5.24","45",null,"In examples 8 and 9, the word \"arrays\" implies more than one array, which a multi-dimensional array is, however it makes the wording awkward.","Change \"arrays\" to \"array\" or \"multidimensional array\".","Changed to:  EXAMPLE 8 In this noncompliant example, a diagnostic is required because a value is stored beyond the end of the arrays in matrix[0] through matrix[4]  when j has values greater than 4."]
["RRB",29,"TL","usrfmt","5.26","49",null,"In example 2, there is a potential array index out of bounds vulnerability due to fc[1]. To focus the vulnerabilities, it should be removed.","Use strncmp instead.","No change made. The buffer is null-terminated by fgets, so fc[1] always exists (and might be null)."]
["RRB",30,"E (Q)","usrfmt","5.26","49",null,"Why is accessing any single character sufficient to sanitize a value (as stated in paragraph 1)? Seems like this should not be the case (for example, comparing to % as any character).",null,"Moved to note:  NOTE Any comparison of a character in the string to a value other than the null character may be considered to sanitize the string."]
["RRB",31,"TL","usrfmt","5.26","50",null,"In example 3, the snprintf function is also a formatted I/O function (7.21.6 in the C standard) but does not have the \"diagnostic required\" comment.","Add a \"// diagnostic required\" after the snprintf line.","Added comment to explain that this line does not need to be diagnosed."]
["RRB",32,"TL","inverrno","5.27","53",null,"Another vulnerability (not setting errno to 0) is also a part of example 2.","Add \"errno = 0;\" as the first statement in the function to focus on the not checking return value aspect vs the setting errno to 0 aspect.","Done."]
["RRB",33,"E","inverrno","5.27","53",null,"In example 3, someone may not know setlocale does not set errno.","Add in the description that setlocale does not explicitly set errno to make it clear. Ex. At the end of the description add \", which does not set errno\"","Done."]
["RRB",34,"TL","libmod","5.30","57",null,"Another vulnerability (buffer overflow) is also a part of example 4 since int can have more digits than the buffer holds.","Change \"16\" to \"BUFFER_SIZE\" to avoid the potential buffer overflow vulnerability in the sprintf call.","Done."]
["RRB",35,"E","uninitref","5.35","61",null,"The missed case which causes the uninitialized variable is not immediately obvious in example 1.","Add in a comment to the \"number > 0\" conditional saying the \"number == 0 case is not covered\" to make the unitialization case clear.","Done."]
["RRB",36,"E","taintformatio","5.40","65",null,"A definition of tainted value is given for this rule but not others.","Remove the line right before example 1.","Done."]
["RRB",37,"TL","chreof","5.43","68",null,"Character types are used in example 2 instead of wide character types.","In example 2, change \"char buf[...\" to \"wchar_t buf[...\" and printf to wprintf.","Done."]
["RRB",38,"TL","resident","5.44","70",null,"In examples 4 and 5, size_t is used in places where a particular integer type should be used as size_t could have values larger than unsigned int (implied by 7.19#4) which may cause another vulnerability.","Change the size_t to unsigned int.","Done."]
["RRB",39,"TL","resident","5.44","70",null,"stdint.h is not included in example 6's code. Isn't the name reserved only if the header is included?","Add in \"#include <stdint.h>\" to the beginning of example 6's code.","Changed to: EXAMPLE 6 In this noncompliant example, a diagnostic is required if header <stdint.h>  is included because the identifiers SIZE_MAX is reserved and the identifier INTFAST16_LIMIT_MAX is reserved because it begins with INT and ends with _MAX."]
["RRB",40,"TL","resident","5.44","70",null,"In examples 6 and 7, what is PRIdFAST16 without stdint.h?","Either include stdint.h as the correction above, or define PRIdFAST16.","Same as immediately above."]
["RRB",41,"E","taintsink","5.46","72",null,"\"Error! Reference source not found\" text present.","Replace with expected reference.","Done."]
["RRB",42,"E",null,"A","74",null,"The point \"Example\" is alone by itself. What does this mean? Doesn't seem to follow a list of transformation techniques as the other points seem to.","Make the point list a contents list.","Done."]
["RRB",43,"E",null,"A.1","74",null,"The first two examples seem to be a part of a single program even though they are separate.","Separate the first two examples as in A.2 with the text \"or\" between them.","Done."]
["rhs",1,"TL",null,"2","2",null,"The sentence \"Conforming analyzers shall diagnose transformations of these rules requiring interprocedural analysis.\" should be stricken because it creates a normative requirement contrary to the non-normative status of Appendix A.","Strike this sentence.","Done."]
["rhs",2,"TL",null,"2.3","3",null,"The sentence \"Implementers are required to distinguish violations that involve tainted values from those that do not involve tainted values.\" imposes a requirement to distinguish two different kinds of violation reporting when there is not a requirement to include the information it requires be distinguished in violation reports in the first place.  It is specifying \"presentation layer\" details that are out of the scope of this standard.","\"Implementers are encouraged to distinguish violations that involve tainted values from those that do not involve tainted values.\"","Done."]
["rhs",3,"TL",null,"Introduction","vii",null,"The sentence \"Because security is the primary concern, these rules are intended first and foremost for evaluating new code and secondarily for evaluating legacy code.\" does not accurately convey the balance struck in the formulation of these rules.  It will be a very long time, if ever, before security-relevant code written after the creation of this standard dominates \"legacy\" code, by which we mean simply any code written prior to this standard.  Rules that hinder adoption by developers of legacy code, even if they would provide some incremental benefit for new development, are likely to result in a net reduction in the security of all C code.","Strike this sentence.  Or replace with: \"There is an inherent conflict between the desire to create rules that are optimal for new development and the desire to avoid creating security-neutral \"clean-up\" work for developers of legacy code wishing to analyze their code according to this standard, which might hinder adoption.  This standard seeks to avoid any rule formulation that would require diagnosing common intrinsically harmless practices.\"","Modified text."]
["rhs",4,"TL",null,"2.4.2","4",null,"The sentence \"Certain parameters of certain library functions are restricted sinks because these functions perform address arithmetic with these parameters, or control the allocation of a resource, or pass these parameters on to another taintededness sink.\" contains a misspelling masking a terminological error: the term \"taintedness sink\" has been uniformly replaced with \"restricted sink\".","Change \"taintededness\" to \"restricted\".","Done."]
["rhs",5,"TL",null,"2.4.2","4",null,"The sentence \"Loop bounds are not restricted sinks.\" should be stricken because it is not this standard's place to limit what an analyzer may choose to diagnose.  In particular, the exact definition of what should and should not be considered a direct or indirect restricted sink is by no means a settled question.","Strike this sentence.","Done."]
["rhs",6,"TL",null,"2.4.3","4",null,"This section omits propagation of taint through flow-of-control.","Add second paragraph: \"Although the exit condition of a loop is not normally itself considered to be a restricted sink, a loop whose exit condition depends on a tainted value propagates taint to any numeric or pointer variables that are increased or decreased by amounts proportional to the number of iterations of the loop.\"","Done."]
["rhs",7,"TL",null,"2.4.5","4",null,"This section is overly biased towards tainted scalar values.","Add sentence: \"This description is suitable for numerical values, but sanitzation of string with respect to content is much more difficult to recognize in a general way.\"","Done."]
["rhs",8,"E",null,"4.5","6",null,"The first bullet item -  \"if E is a subtraction expression (-) whose operands both are of pointer type, then T is the type pointed to by the operands of the expression;\" -- apears entiely in italics.  Only the variable names 'E' and 'T' should appear in italics.","if E is a subtraction expression (-) whose operands both are of pointer type, then T is the type pointed to by the operands of the expression;","Definition deleted."]
["rhs",9,"TL",null,"4.5","6",null,"The definition of \"derived type\" does not cover multiplication.","Add bullet item: \"An integer expression NDT * DT (or DT  * NDT), where NDT is a constant with no derived type and DT is an expression with derived type T, has derived type T.\"","Definition deleted."]
["rhs",10,"TL",null,"Annex A","73-76",null,"This annex was derived from an informal white paper used to prompt discussion.  In its current form it was not intended for direct inclusion in the standard.  It also focuses on bottom-up and top-down interprocedurdal analysis to the exclusion of global data flow issues.","See document N1621  for replacement text for all of Annex A.","Done."]
["BG",1,"GT",null,"2","1","last","The actual conformance rule “A conforming analyzer shall issue at least one diagnostic for a program containing one or more violations” is inconsistent with the prior statement (on the same page) “A conforming analyzer shall diagnose all violations of coding rules specified in this Technical Specification.”","A conforming analyzer shall issue at least one diagnostic for a program for each violation.","Replaced with: \"A conforming analyzer shall be capable of producing a diagnostic for each distinct rule in the Technical Specification upon encountering a violation of that rule in isolation.\""]
["BG",2,"GT",null,"2","2","1","“For each distinct rule in this Technical Specification, a conforming analyzer shall be capable of producing a distinct diagnostic”\nThe term ‘capable’ isn’t measurable.\n","For each distinct rule in this Technical Specification, a conforming analyzer shall produce a distinct diagnostic upon detection of a violation of that rule.","This text has been modified."]
["BG",3,"GT",null,"2","2",null,"Conforming analyzers shall diagnose transformations of these rules requiring interprocedural analysis.\nThe rules of intraprocedural transformations, either by optimizers or analyzers, are not well defined, and are certainly not adequately defined by the non-normative annex supplied.  The transforms have to be well defined for this statement to have normative meaning.","Conforming analyzers may diagnose transformations of these rules requiring interprocedural analysis.","The phrase interprocedural analysis has been removed from the introduction and the conformance sections."]
["BG",4,"GT",null,"completeness and soundness","2",null,"The analyzer shall report a diagnostic for at least one program that contains a violation of each rule.\nAmbiguity - one program with all violations or one violation per program.","For each rule, The analyzer shall report a diagnostic for at least one program that contains a violation of that rule","Change made."]
["BG",5,"E",null,"completeness and soundness","2",null,"There are many tradeoffs… outside the the scope of this specification.\nI don’t see the value of discussing tradeoffs for non-conformance.","There are many tradeoffs outside the the scope of this specification.","This text has been moved to the introduction."]
["BG",6,"E",null,"completeness and soundness","2",null,"In practice, tools needs to strike a balance between the two.\n","In practice, tools need to strike a balance between the two.\n","Fixed."]
["BG",7,"E",null,"security focus","3",null,"To be considered a security flaw, a software bug must be triggered by the actions of a malicious user or attacker.","To be considered a security flaw, a software bug must be able to be triggered by the actions of a malicious user or attacker.","Changed to \"a software bug must be triggerable \""]
["BG",8,"E",null,"security focus","3",null,"Implementers are required to distinguish violations that involve tainted values from those that do not involve tainted values.\nSounds normative but without normative language, and yet also uses as yet undefined terms.","Implementers will need to distinguish violations that involve what will be defined as tainted values from those that do not involve tainted values.","Change made."]
["BG",9,"GT",null,"taint analysis","3","last","the input values or strings produced by getenv, fscanf, vfscanf, vscanf, fgets, fread, fwscanf, vfwscanf, vwscanf, wscanf, and fgetws.\nArent the inputs sinks?","the  strings produced by getenv, fscanf, vfscanf, vscanf, fgets, fread, fwscanf, vfwscanf, vwscanf, wscanf, and fgetws.","Change made."]
["BG",10,"E",null,"2.1.2","4",null,"Certain parameters of certain library functions are restricted sinks because these functions perform address arithmetic with these parameters, or control the allocation of a resource, or pass these parameters on to another taintededness sink.","Certain parameters of certain library functions are restricted sinks because these functions perform address arithmetic with these parameters, or control the allocation of a resource, or pass these parameters on to another tainted sink.","Changed to \"restricted sink\"."]
["BG",11,"TH",null,"2.1.2","4",null,"“All string input parameters to library functions are restricted sinks because those strings are required to be null-terminated,”, yet “arguments whose domain is a subset of the domain described by their types are called restricted sinks.”, so I don’t think the null terminated C String convention can be regarded as a type.  What about variadic structures with char[] as the last element?\n","For purposes of this TS we regard char * as a reference to a null terminated array of characters.","The standard is clear as to which char * parameters are pointers to strings. Added: For purposes of this Technical Specification, we regard char * as a reference to a null-terminated array of characters."]
["BG",12,"GT",null,"2.1.4","4",null,"section not necessary nor very useful","By definition, any tainted value flowing into a restricted sink is a security issue, so all such cases shall be diagnosed.\n","Removed section."]
["BG",13,"E",null,"4.1","6",null,"analyzer can be a code reviewer?  For this TS??","NOTE Analyzers may include static analysis tools, tools within a compiler suite, or tools in other contexts.","Change made."]
["BG",14,"E",null,"4.2","6",null,"join “-signal safe”  “ function that”",null,"This was meant to be an alternate term, so I added another \"function\" to make this clear: asynchronous-safe function\nasynchronous-signal safe function\nfunction that can be called safely and without side effects from within a signal-handler \n"]
["BG",15,"E",null,"4.3","6",null,"data flow analysis\ntracking of values along specific paths through the code\n","tracking of value constraints along non-excluded paths through the code","Change made."]
["BG",16,"E",null,"4.4","6",null,"dereferenceable pointer\nvalid pointer that points to an object in memory","dereferenceable pointer\na pointer that contains the address of an object in memory","Definition is not used in the text and has been removed."]
["BG",17,"TH",null,"4.5","6",null,"derived type\nconflicts with C11 definition\n","subject type","Use of derived type has been eradicated from the document."]
["BG",18,"E",null,"4.6","7",null,"4.6 exploit\nsoftware or technique that takes advantage\n","4.6 exploit \ntechnique that takes advantage","Change made."]
["BG",19,"TL",null,"4.7","7",null,"mutiliated","mutiliated value","Change made."]
["BG",20,"E",null,"50","72",null,"and are used in an integer Error! Reference source not found. shall be diagnosed\n","and are used in an integer expression shall be diagnosed\n","Fixed."]
[{"$nulls":8},"Rule 5.20, sec. 5.20.4 examples","changed \"parameter\" to \"argument\" in examples"]

{"sheet":"Categories","index":1,"n_rows":21,"n_cols":1,"rows_kept":21}
["Impact rank     Category code     Category title"]
["    1               GT            General Technical"]
["    2               TH            Technical High (major)"]
["    3               TL            Technical Low (minor)"]
["    4               GE            General Editorial"]
["    5               E             Editorial"]
[]
["General Technical"]
["Covers a Technical problem that exists in many places throughout the document. The many occurrences make this the highest impact category. It is preferable to use specific individual references to each case instead of this category if at all possible."]
[]
["Technical High"]
["Major technical problems. Proposed replacement text is mandatory."]
[]
["Technical Low"]
["Minor problems. These problems are often of a more significant nature than a simple editorial change. Proposed new text is mandatory."]
[]
["General Editorial"]
["Covers an Editorial problem that exists in many places throughout the document. For example, correct spelling from “organisation” to “organization” for all occurrences. It is preferable to use specific individual references to each case instead of this category if at all possible."]
[]
["Editorial"]
["Covers grammar, missing or duplicated text, missing or incorrect cross-references, incorrect numbering, spelling and punctuation problems. These are all matters that should be able to be resolved offline by the Project Editor.  Terminology changes are not Editorial.  Proposed new text is requested to facilitate document updating."]