Secure Coding Standard¶

The strongSwan project adheres to the following recommendations and rules proposed by the CERT C Secure Coding Standard:

• Table of contents
• Secure Coding Standard
  • Preprocessor (PRE)
    • Full Adherence
    • Partial Adherence
    • Check Adherence
    • No Adherence
  • Declarations and Initialization (DCL)
    • Full Adherence
    • Partial Adherence
    • Check Adherence
    • No Adherence
  • Expressions (EXP)
  • Integers (INT)
  • Floating Point (FLP)
  • Arrays (ARR)
  • Characters and Strings (STR)
  • Memory Management (MEM)
  • Input Output (FIO)
  • Environment (ENV)
  • Signals (SIG)
  • Error Handling (ERR)
  • Application Programming Interfaces (API)
  • Concurrency (CON)
  • Miscellaneous (MSC)
  • POSIX (POS)

Preprocessor (PRE)¶

Full Adherence¶

• PRE03-C. Prefer typedefs to defines for encoding types

• PRE04-C. Do not reuse a standard header file name

• PRE06-C. Enclose header files in an inclusion guard

• PRE09-C. Do not replace secure functions with deprecated or obsolescent functions

Partial Adherence¶

• PRE00-C. Prefer inline or static functions to function-like macros

• PRE01-C. Use parentheses within macros around parameter names

• PRE02-C. Macro replacement lists should be parenthesized

Check Adherence¶

• PRE05-C. Understand macro replacement when concatenating tokens or performing stringification

• PRE07-C. Avoid using repeated question marks

• PRE10-C. Wrap multistatement macros in a do-while loop

• PRE11-C. Do not conclude macro definitions with a semicolon

• PRE12-C. Do not define unsafe macros

• PRE30-C. Do not create a universal character name through concatenation

• PRE31-C. Avoid side-effects in arguments to unsafe macros

• PRE32-C. Do not use preprocessor directives inside macro arguments

No Adherence¶

• PRE08-C. Guarantee that header file names are unique

Declarations and Initialization (DCL)¶

Full Adherence¶

• DCL01-C. Do not reuse variable names in subscopes

• DCL02-C. Use visually distinct identifiers

• DCL05-C. Use typedefs to improve code readability

• DCL07-C. Include the appropriate type information in function declarators

• DCL12-C. Implement abstract data types using opaque types

• DCL15-C. Declare file-scope objects or functions that do not need external linkage as static

• DCL18-C. Do not begin integer constants with 0 when specifying a decimal value

• DCL31-C. Declare identifiers before using them

Partial Adherence¶

• DCL06-C. Use meaningful symbolic constants to represent literal values

• DCL19-C. Minimize the scope of variables and functions

• DCL20-C. Always specify void even if a function accepts no arguments

Check Adherence¶

• DCL08-C. Properly encode relationships in constant definitions

• DCL09-C. Declare functions that return errno with a return type of errno_t

• DCL10-C. Maintain the contract between the writer and caller of variadic functions

• DCL11-C. Understand the type issues associated with variadic functions

• DCL16-C. Use 'L,' not 'l,' to indicate a long value

• DCL17-C. Beware of miscompiled volatile-qualified variables

• DCL21-C. Understand the storage of compound literals

• DCL30-C. Declare objects with appropriate storage durations

• DCL34-C. Use volatile for data that cannot be cached

No Adherence¶

• DCL00-C. Const-qualify immutable objects

• DCL03-C. Use a static assertion to test the value of a constant expression

• DCL04-C. Do not declare more than one variable per declaration

• DCL13-C. Declare function parameters that are pointers to values not changed by the function as const

• DCL32-C. Guarantee that mutually visible identifiers are unique

Expressions (EXP)¶

Integers (INT)¶

Floating Point (FLP)¶

Arrays (ARR)¶

Characters and Strings (STR)¶

Memory Management (MEM)¶

Input Output (FIO)¶

Environment (ENV)¶

Signals (SIG)¶

Error Handling (ERR)¶

Application Programming Interfaces (API)¶

Concurrency (CON)¶

Miscellaneous (MSC)¶

POSIX (POS)¶