Information technology - Programming languages, their environments and system software interfaces - C secure coding rules
Scope:
Scope
This Technical Specification specifies
- rules for secure coding in the C programming language and
- code examples.
This Technical Specification does not specify
- the mechanism by which these rules are enforced or
- any particular coding style to be enforced. (It has been impossible to develop a consensus on appropriate style guidelines. Programmers should define style guidelines and apply these guidelines consistently. The easiest way to consistently apply a coding style is with the use of a code formatting tool. Many interactive development environments provide such capabilities.)
Each rule in this Technical Specification is accompanied by code examples. Code examples are informative only and serve to clarify the requirements outlined in the normative portion of the rule. Examples impose no normative requirements.
Each rule in this Technical Specification that is based on undefined behavior defined in the C Standard identifies the undefined behavior by a numeric code. The numeric codes for undefined behaviors can be found in Annex B, Undefined Behavior.
Two distinct kinds of examples are provided:
- noncompliant examples demonstrating language constructs that have weaknesses with potentially exploitable security implications; such examples are expected to elicit a diagnostic from a conforming analyzer for the affected language construct; and
- compliant examples are expected not to elicit a diagnostic.
Examples are not intended to be complete programs. For brevity, they typically omit #include directives of C Standard Library headers that would otherwise be necessary to provide declarations of referenced symbols. Code examples may also declare symbols without providing their definitions if the definitions are not essential for demonstrating a specific weakness.
Some rules in this Technical Specification have exceptions. Exceptions are part of the specification of these rules and are normative.
Project need:
Note: The information provided above was obtained by the Standards Council of Canada (SCC) and is provided as part of a centralized, transparent notification system for new standards development. The system allows SCC-accredited Standards Development Organizations (SDOs), and members of the public, to be informed of new work in Canadian standards development, and allows SCC-accredited SDOs to identify and resolve potential duplication of standards and effort.
Individual SDOs are responsible for the content and accuracy of the information presented here. The text is presented in the language in which it was provided to SCC.