The CERT C guidelines consist of “recommendations” and “rules” organized into 17 sections. The name of a
guideline consists of a 3-character mnemonic corresponding to the section, a 2-digit number in the range of 00-99,
and a suffix (which is always -C for CERT C). Guidelines with a number in the range 00-29 are recommendations
and guidelines in the range 30-99 are rules.
PC-lint Plus provides support for detecting violations of the CERT C guidelines using the au-certc.lnt file
distributed with the product in the lnt/ directory. The tables that follow detail the level of support and the
supporting messages for each guideline. While some of the messages are specific to CERT C guidelines, any of the
messages may be employed individually in order to make use of a subset of the checks, outside of CERT C
compliance checking.
The author file enables checks for both library and non-library code. This means that the standard
headers employed by your source code are subject to the same scrutiny as the rest of the project.
This is often a project requirement but can result in a lot of noise if library code is not subject to the
same compliance requirements as the rest of the project. The simplest way to disable CERT C
checks for library code is to place the options -wlib(4) -wlib(1) immediately after the
author file is referenced. This raises and immediately lowers the warning level for libraries
resulting in a suppression of all non-error messages from library code. Any non-error
messages that you intend to enable for library code (e.g. via +elib) should appear after these
options.
The theoretical ability for static analysis to detect violations of guidelines vary. Some guidelines (macro replacement
lists should be parenthesized) can theoretically always be detected with static analysis methods whereas other
guidelines (prefer inline or static functions to function-like macros) are subjective and/or not statically checkable. A
guideline is considered to be “Decidable” if all violations of the guidelines can theoretically be detected with static
analysis means and not decidable if the rule is either inherently not statically checkable or cannot be diagnosed in
all cases.
The following terms are used to characterize the support that PC-lint Plus provides each guideline:
Supported - For statically checkable guidelines, the rule is comprehensively supported and no false positives nor false negatives are expected. For guidelines that are not fully statically checkable, substantial support is provided to detect statically checkable violations.
Partially Supported - Meaningful support is provided but there may be cases where false positives and/or false negatives may occur due to limitations in the currently implemented detection method, one or more guideline exceptions are not implemented, etc.
Assistance Provided - While enforcement of the actual guideline is not supported (or cannot be statically checked), potential violations of the guideline are diagnosed.
Not Supported - No meaningful level of support is currently provided for this guideline.
Not Statically Checkable - Violations of the guideline cannot be detected by means of static analysis.
Most guidelines marked as Partially Supported or Assistance Provided contain a footnote that corresponds to an explanation of the corresponding limitation(s) at the end of this section.
An example of a guideline that is not supported is PRE08-C (Guarantee that header file names are unique). The
guideline is statically checkable but PC-lint Plus does not currently have a diagnostic to support the
guideline.
An example of “Assistance provided” is PRE00-C (Prefer inline or static functions to function-like macros). The
rule is not statically checkable in a meaningful way but PC-lint Plus can diagnose the definition of
function-like macros and the message can be suppressed for those macros deemed to be legitimately
necessary.
An example of “Partially supported” is DCL04-C (Do not declare more than one variable per declaration). This
guideline is supported except for two exceptions to the recommendation that are not honored by the enforcement
mechanism which may result in false positives.
An example of a “Supported” guideline is PRE02-C (Macro replacement lists should be parenthesized). This
guideline is decidable and PC-lint Plus fully supports this guideline. Another example is EXP33-C (Do not read
uninitialized memory). While this rule is undecidable (and therefore exhaustive support is impossible), PC-lint
Plus provides substantial support for the rule and will catch a wide variety of statically checkable
violations.
CERT C guideline titles are excerpted from SEI CERT C Coding Standard © Carnegie Mellon University 1995–2016. See chapter 25 for full details.
| Supported | 154 | 51.7% |
| Comprehensive | 78 | 26.2% |
| Partial | 55 | 18.5% |
| Assistance | 21 | 7.0% |
| Not Supported | 144 | 48.3% |
| Not Statically Checkable | 8 |
|
| TOTAL | 306 |
|
| PRE00-C | Prefer inline or static functions to function-like macros | Assistance provided | |
| PRE01-C | Use parentheses within macros around parameter names | Supported | |
| PRE02-C | Macro replacement lists should be parenthesized | Supported | |
| PRE03-C | Prefer typedefs to defines for encoding non-pointer types | Not supported |
|
| PRE04-C | Do not reuse a standard header file name | Not supported |
|
| PRE05-C | Understand macro replacement when concatenating tokens or performing stringification | Assistance provided1 | |
| PRE06-C | Enclose header files in an include guard | Supported | |
| PRE07-C | Avoid using repeated question marks | Supported | |
| PRE08-C | Guarantee that header file names are unique | Not supported |
|
| PRE09-C | Do not replace secure functions with deprecated or obsolescent functions | Not supported |
|
| PRE10-C | Wrap multistatement macros in a do-while loop | Supported | |
| PRE11-C | Do not conclude macro definitions with a semicolon | Supported | |
| PRE12-C | Do not define unsafe macros | Not supported |
|
| PRE13-C | Use the Standard predefined macros to test for versions and features. | Not supported |
|
| PRE30-C | Do not create a universal character name through concatenation | Not supported |
|
| PRE31-C | Avoid side effects in arguments to unsafe macros | Supported | |
| PRE32-C | Do not use preprocessor directives in invocations of function-like macros | Supported | |
| DCL00-C | Const-qualify immutable objects | Supported | |
| DCL01-C | Do not reuse variable names in subscopes | Supported | |
| DCL02-C | Use visually distinct identifiers | Partially supported2 | |
| DCL03-C | Use a static assertion to test the value of a constant expression | Not supported |
|
| DCL04-C | Do not declare more than one variable per declaration | Partially supported3 | |
| DCL05-C | Use typedefs of non-pointer types only | Not supported |
|
| DCL06-C | Use meaningful symbolic constants to represent literal values | Not supported |
|
| DCL07-C | Include the appropriate type information in function declarators | Supported | |
| DCL08-C | Properly encode relationships in constant definitions | Not statically checkable |
|
| DCL09-C | Declare functions that return errno with a return type of errno_t | Not supported |
|
| DCL10-C | Maintain the contract between the writer and caller of variadic functions | Assistance provided4 | |
| DCL11-C | Understand the type issues associated with variadic functions | Assistance provided4 | |
| DCL12-C | Implement abstract data types using opaque types | Not supported |
|
| DCL13-C | Declare function parameters that are pointers to values not changed by the function as const | Supported | |
| DCL15-C | Declare file-scope objects or functions that do not need external linkage as static | Supported | |
| DCL16-C | Use "L," not "l," to indicate a long value | Supported | |
| DCL17-C | Beware of miscompiled volatile-qualified variables | Not supported |
|
| DCL18-C | Do not begin integer constants with 0 when specifying a decimal value | Supported | |
| DCL19-C | Minimize the scope of variables and functions | Partially supported | |
| DCL20-C | Explicitly specify void when a function accepts no arguments | Partially supported | |
| DCL21-C | Understand the storage of compound literals | Not supported |
|
| DCL22-C | Use volatile for data that cannot be cached | Not supported |
|
| DCL23-C | Guarantee that mutually visible identifiers are unique | Supported | |
| DCL30-C | Declare objects with appropriate storage durations | Partially supported | |
| DCL31-C | Declare identifiers before using them | Supported | |
| DCL36-C | Do not declare an identifier with conflicting linkage classifications | Supported | |
| DCL37-C | Do not declare or define a reserved identifier | Partially supported | |
| DCL38-C | Use the correct syntax when declaring a flexible array member | Supported | |
| DCL39-C | Avoid information leakage when passing a structure across a trust boundary | Not supported |
|
| DCL40-C | Do not create incompatible declarations of the same function or object | Supported | |
| DCL41-C | Do not declare variables inside a switch statement before the first case label | Assistance provided | |
| EXP00-C | Use parentheses for precedence of operation | Supported | |
| EXP02-C | Be aware of the short-circuit behavior of the logical AND and OR operators | Supported | |
| EXP03-C | Do not assume the size of a structure is the sum of the sizes of its members | Not supported |
|
| EXP05-C | Do not cast away a const qualification | Partially supported | |
| EXP07-C | Do not diminish the benefits of constants by assuming their values in expressions | Not supported |
|
| EXP08-C | Ensure pointer arithmetic is used correctly | Partially supported | |
| EXP09-C | Use sizeof to determine the size of a type or variable | Not supported |
|
| EXP10-C | Do not depend on the order of evaluation of subexpressions or the order in which side effects take place | Partially supported | |
| EXP11-C | Do not make assumptions regarding the layout of structures with bit-fields | Not supported |
|
| EXP12-C | Do not ignore values returned by functions | Supported | |
| EXP13-C | Treat relational and equality operators as if they were nonassociative | Supported | |
| EXP14-C | Beware of integer promotion when performing bitwise operations on integer types smaller than int | Not supported |
|
| EXP15-C | Do not place a semicolon on the same line as an if, for, or while statement | Partially supported5 | |
| EXP16-C | Do not compare function pointers to constant values | Partially supported6 | |
| EXP19-C | Use braces for the body of an if, for, or while statement | Supported | |
| EXP20-C | Perform explicit tests to determine success, true and false, and equality | Partially supported7 | |
| EXP30-C | Do not depend on the order of evaluation for side effects | Partially supported | |
| EXP32-C | Do not access a volatile object through a nonvolatile reference | Not supported |
|
| EXP33-C | Do not read uninitialized memory | Supported | |
| EXP34-C | Do not dereference null pointers | Partially supported | |
| EXP35-C | Do not modify objects with temporary lifetime | Not supported |
|
| EXP36-C | Do not cast pointers into more strictly aligned pointer types | Partially supported8 | |
| EXP37-C | Call functions with the correct number and type of arguments | Not supported |
|
| EXP39-C | Do not access a variable through a pointer of an incompatible type | Not supported |
|
| EXP40-C | Do not modify constant objects | Not supported |
|
| EXP42-C | Do not compare padding data | Assistance provided9 | |
| EXP43-C | Avoid undefined behavior when using restrict-qualified pointers | Assistance provided10 | |
| EXP44-C | Do not rely on side effects in operands to sizeof, _Alignof, or _Generic | Partially supported11 | |
| EXP45-C | Do not perform assignments in selection statements | Partially supported12 | |
| EXP46-C | Do not use a bitwise operator with a Boolean-like operand | Supported | |
| EXP47-C | Do not call va_arg with an argument of the incorrect type | Assistance provided13 | |
| INT00-C | Understand the data model used by your implementation(s) | Assistance provided14 | |
| INT01-C | Use rsize_t or size_t for all integer values representing the size of an object | Not supported |
|
| INT02-C | Understand integer conversion rules | Partially supported | |
| INT04-C | Enforce limits on integer values originating from tainted sources | Not supported |
|
| INT05-C | Do not use input functions to convert character data if they cannot handle all possible inputs | Supported | |
| INT07-C | Use only explicitly signed or unsigned char type for numeric values | Supported | |
| INT08-C | Verify that all integer values are in range | Partially supported | |
| INT09-C | Ensure enumeration constants map to unique values | Partially supported | |
| INT10-C | Do not assume a positive remainder when using the % operator | Not supported |
|
| INT12-C | Do not make assumptions about the type of a plain int bit-field when used in an expression | Supported | |
| INT13-C | Use bitwise operators only on unsigned operands | Partially supported15 | |
| INT14-C | Avoid performing bitwise and arithmetic operations on the same data | Not supported |
|
| INT15-C | Use intmax_t or uintmax_t for formatted IO on programmer-defined integer types | Not supported |
|
| INT16-C | Do not make assumptions about representation of signed integers | Partially supported16 | |
| INT17-C | Define integer constants in an implementation-independent manner | Not supported |
|
| INT18-C | Evaluate integer expressions in a larger size before comparing or assigning to that size | Not supported |
|
| INT30-C | Ensure that unsigned integer operations do not wrap | Not supported |
|
| INT31-C | Ensure that integer conversions do not result in lost or misinterpreted data | Not supported |
|
| INT32-C | Ensure that operations on signed integers do not result in overflow | Not supported |
|
| INT33-C | Ensure that division and remainder operations do not result in divide-by-zero errors | Not supported |
|
| INT34-C | Do not shift an expression by a negative number of bits or by greater than or equal to the number of bits that exist in the operand. | Not supported |
|
| INT35-C | Use correct integer precisions | Not supported |
|
| INT36-C | Converting a pointer to integer or integer to pointer | Partially supported17 | 4287 |
| FLP00-C | Understand the limitations of floating-point numbers | Partially supported | |
| FLP01-C | Take care in rearranging floating-point expressions | Not statically checkable |
|
| FLP02-C | Avoid using floating-point numbers when precise computation is needed | Partially supported | |
| FLP03-C | Detect and handle floating-point errors | Assistance provided | |
| FLP04-C | Check floating-point inputs for exceptional values | Not supported |
|
| FLP05-C | Do not use denormalized numbers | Not supported |
|
| FLP06-C | Convert integers to floating point for floating-point operations | Supported | |
| FLP07-C | Cast the return value of a function that returns a floating-point type | Not supported |
|
| FLP30-C | Do not use floating-point variables as loop counters | Supported | |
| FLP32-C | Prevent or detect domain and range errors in math functions | Partially supported18 | |
| FLP34-C | Ensure that floating-point conversions are within range of the new type | Partially supported | |
| FLP36-C | Preserve precision when converting integral values to floating-point type | Partially supported | |
| FLP37-C | Do not use object representations to compare floating-point values | Supported | |
| ARR00-C | Understand how arrays work | Partially supported19 | |
| ARR01-C | Do not apply the sizeof operator to a pointer when taking the size of an array | Supported | |
| ARR02-C | Explicitly specify array bounds, even if implicitly defined by an initializer | Partially supported | |
| ARR30-C | Do not form or use out-of-bounds pointers or array subscripts | Supported | |
| ARR32-C | Ensure size arguments for variable length arrays are in a valid range | Assistance provided | |
| ARR36-C | Do not subtract or compare two pointers that do not refer to the same array | Not supported |
|
| ARR37-C | Do not add or subtract an integer to a pointer to a non-array object | Partially supported | |
| ARR38-C | Guarantee that library functions do not form invalid pointers | Partially supported | |
| ARR39-C | Do not add or subtract a scaled integer to a pointer | Not supported |
|
| STR00-C | Represent characters using an appropriate type | Not statically checkable |
|
| STR01-C | Adopt and implement a consistent plan for managing strings | Not statically checkable |
|
| STR02-C | Sanitize data passed to complex subsystems | Not supported |
|
| STR03-C | Do not inadvertently truncate a string | Not supported |
|
| STR04-C | Use plain char for characters in the basic character set | Not supported |
|
| STR05-C | Use pointers to const when referring to string literals | Supported | |
| STR06-C | Do not assume that strtok() leaves the parse string unchanged | Not supported |
|
| STR07-C | Use the bounds-checking interfaces for string manipulation | Supported | |
| STR09-C | Don’t assume numeric values for expressions with type plain character | Supported | |
| STR10-C | Do not concatenate different type of string literals | Supported | |
| STR11-C | Do not specify the bound of a character array initialized with a string literal | Partially supported | |
| STR30-C | Do not attempt to modify string literals | Partially supported | |
| STR31-C | Guarantee that storage for strings has sufficient space for character data and the null terminator | Partially supported | |
| STR32-C | Do not pass a non-null-terminated character sequence to a library function that expects a string | Not supported |
|
| STR34-C | Cast characters to unsigned char before converting to larger integer sizes | Partially supported | |
| STR37-C | Arguments to character-handling functions must be representable as an unsigned char | Supported | |
| STR38-C | Do not confuse narrow and wide character strings and functions | Partially supported20 | |
| MEM00-C | Allocate and free memory in the same module, at the same level of abstraction | Partially supported | |
| MEM01-C | Store a new value in pointers immediately after free() | Not supported |
|
| MEM02-C | Immediately cast the result of a memory allocation function call into a pointer to the allocated type | Assistance provided21 | |
| MEM03-C | Clear sensitive information stored in reusable resources | Not supported |
|
| MEM04-C | Beware of zero-length allocations | Not supported |
|
| MEM05-C | Avoid large stack allocations | Partially supported22 | |
| MEM06-C | Ensure that sensitive data is not written out to disk | Not supported |
|
| MEM07-C | Ensure that the arguments to calloc(), when multiplied, do not wrap | Not supported |
|
| MEM10-C | Define and use a pointer validation function | Not supported |
|
| MEM11-C | Do not assume infinite heap space | Assistance provided23 | |
| MEM12-C | Consider using a goto chain when leaving a function on error when using and releasing resources | Assistance provided | |
| MEM30-C | Do not access freed memory | Supported | |
| MEM31-C | Free dynamically allocated memory when no longer needed | Supported | |
| MEM33-C | Allocate and copy structures containing a flexible array member dynamically | Not supported |
|
| MEM34-C | Only free memory allocated dynamically | Supported | |
| MEM35-C | Allocate sufficient memory for an object | Partially supported | |
| MEM36-C | Do not modify the alignment of objects by calling realloc() | Not supported |
|
| FIO01-C | Be careful using functions that use file names for identification | Not supported |
|
| FIO02-C | Canonicalize path names originating from tainted sources | Not supported |
|
| FIO03-C | Do not make assumptions about fopen() and file creation | Not supported |
|
| FIO05-C | Identify files using multiple file attributes | Not supported |
|
| FIO06-C | Create files with appropriate access permissions | Not supported |
|
| FIO08-C | Take care when calling remove() on an open file | Not supported |
|
| FIO09-C | Be careful with binary data when transferring data across systems | Not supported |
|
| FIO10-C | Take care when using the rename() function | Not supported |
|
| FIO11-C | Take care when specifying the mode parameter of fopen() | Supported | |
| FIO13-C | Never push back anything other than one read character | Supported | |
| FIO14-C | Understand the difference between text mode and binary mode with file streams | Not supported |
|
| FIO15-C | Ensure that file operations are performed in a secure directory | Not supported |
|
| FIO17-C | Do not rely on an ending null character when using fread() | Not supported |
|
| FIO18-C | Never expect fwrite() to terminate the writing process at a null character | Not supported |
|
| FIO19-C | Do not use fseek() and ftell() to compute the size of a regular file | Not supported |
|
| FIO20-C | Avoid unintentional truncation when using fgets() or fgetws() | Not supported |
|
| FIO21-C | Do not create temporary files in shared directories | Not supported |
|
| FIO22-C | Close files before spawning processes | Not supported |
|
| FIO23-C | Do not exit with unflushed data in stdout or stderr | Not supported |
|
| FIO24-C | Do not open a file that is already open | Not supported |
|
| FIO30-C | Exclude user input from format strings | Partially supported24 | |
| FIO32-C | Do not perform operations on devices that are only appropriate for files | Not supported |
|
| FIO34-C | Distinguish between characters read from a file and EOF or WEOF | Not supported |
|
| FIO37-C | Do not assume that fgets() or fgetws() returns a nonempty string when successful | Not supported |
|
| FIO38-C | Do not copy a FILE object | Partially supported25 | |
| FIO39-C | Do not alternately input and output from a stream without an intervening flush or positioning call | Supported | |
| FIO40-C | Reset strings on fgets() or fgetws() failure | Not supported |
|
| FIO41-C | Do not call getc(), putc(), getwc(), or putwc() with a stream argument that has side effects | Not supported |
|
| FIO42-C | Close files when they are no longer needed | Partially supported | |
| FIO44-C | Only use values for fsetpos() that are returned from fgetpos() | Not supported |
|
| FIO45-C | Avoid TOCTOU race conditions while accessing files | Not supported |
|
| FIO46-C | Do not access a closed file | Supported | |
| FIO47-C | Use valid format strings | Supported | 492 493 494 499 557 558 559 566 705 706 719 816 855 2401 2402 2403 2404 2405 2406 2407 |
| ENV01-C | Do not make assumptions about the size of an environment variable | Supported | |
| ENV02-C | Beware of multiple environment variables with the same effective name | Not supported |
|
| ENV03-C | Sanitize the environment when invoking external programs | Not supported |
|
| ENV30-C | Do not modify the object referenced by the return value of certain functions | Supported | |
| ENV31-C | Do not rely on an environment pointer following an operation that may invalidate it | Not supported |
|
| ENV32-C | All exit handlers must return normally | Not supported |
|
| ENV33-C | Do not call system() | Supported | |
| ENV34-C | Do not store pointers returned by certain functions | Not supported |
|
| SIG00-C | Mask signals handled by noninterruptible signal handlers | Assistance provided26 | |
| SIG01-C | Understand implementation-specific details regarding signal handler persistence | Assistance provided26 | |
| SIG02-C | Avoid using signals to implement normal functionality | Assistance provided26 | |
| SIG30-C | Call only asynchronous-safe functions within signal handlers | Supported | |
| SIG31-C | Do not access shared objects in signal handlers | Supported | |
| SIG34-C | Do not call signal() from within interruptible signal handlers | Supported | |
| SIG35-C | Do not return from a computational exception signal handler | Supported | |
| ERR00-C | Adopt and implement a consistent and comprehensive error-handling policy | Not statically checkable |
|
| ERR01-C | Use ferror() rather than errno to check for FILE stream errors | Not supported |
|
| ERR02-C | Avoid in-band error indicators | Not statically checkable |
|
| ERR03-C | Use runtime-constraint handlers when calling the bounds-checking interfaces | Not supported |
|
| ERR04-C | Choose an appropriate termination strategy | Supported | |
| ERR05-C | Application-independent code should provide error detection without dictating error handling | Not supported |
|
| ERR06-C | Understand the termination behavior of assert() and abort() | Supported | |
| ERR07-C | Prefer functions that support error checking over equivalent functions that don’t | Supported | |
| ERR30-C | Set errno to zero before calling a library function known to set errno, and check errno only after the function returns a value indicating failure | Not supported |
|
| ERR32-C | Do not rely on indeterminate values of errno | Not supported |
|
| ERR33-C | Detect and handle standard library errors | Partially supported | |
| ERR34-C | Detect errors when converting a string to a number | Assistance provided | |
| API00-C | Functions should validate their parameters | Partially supported27 | |
| API01-C | Avoid laying out strings in memory directly before sensitive data | Not supported |
|
| API02-C | Functions that read or write to or from an array should take an argument to specify the source or target size | Not supported |
|
| API03-C | Create consistent interfaces and capabilities across related functions | Not statically checkable |
|
| API04-C | Provide a consistent and usable error-checking mechanism | Not statically checkable |
|
| API05-C | Use conformant array parameters | Not supported |
|
| API07-C | Enforce type safety | Not supported |
|
| API08-C | Avoid parameter names in a function prototype | Not supported |
|
| API09-C | Compatible values should have the same type | Partially supported | |
| API10-C | APIs should have security options enabled by default | Not supported |
|
| MSC00-C | Compile cleanly at high warning levels | Not supported |
|
| MSC01-C | Strive for logical completeness | Partially supported | |
| MSC04-C | Use comments consistently and in a readable fashion | Supported | |
| MSC05-C | Do not manipulate time_t typed values directly | Not supported |
|
| MSC06-C | Beware of compiler optimizations | Assistance provided | |
| MSC09-C | Character encoding: Use subset of ASCII for safety | Not supported |
|
| MSC10-C | Character encoding: UTF8-related issues | Not supported |
|
| MSC11-C | Incorporate diagnostic tests using assertions | Not supported |
|
| MSC12-C | Detect and remove code that has no effect or is never executed | Supported | 438 474 505 522 523 527 528 529 563 612 714 715 719 749 750 751 752 753 754 755 756 757 758 768 769 774 827 838 1972 |
| MSC13-C | Detect and remove unused values | Partially supported | |
| MSC14-C | Do not introduce unnecessary platform dependencies | Not supported28 |
|
| MSC15-C | Do not depend on undefined behavior | Not supported29 |
|
| MSC17-C | Finish every set of statements associated with a case label with a break statement | Supported | |
| MSC18-C | Be careful while handling sensitive data, such as passwords, in program code | Partially supported30 | |
| MSC19-C | For functions that return an array, prefer returning an empty array over a null value | Partially supported | |
| MSC20-C | Do not use a switch statement to transfer control into a complex block | Supported | |
| MSC21-C | Use robust loop termination conditions | Partially supported | |
| MSC22-C | Use the setjmp(), longjmp() facility securely | Not supported |
|
| MSC23-C | Beware of vendor-specific library and language differences | Not supported |
|
| MSC24-C | Do not use deprecated or obsolescent functions | Supported | |
| MSC30-C | Do not use the rand() function for generating pseudorandom numbers | Supported | |
| MSC32-C | Properly seed pseudorandom number generators | Supported | |
| MSC33-C | Do not pass invalid data to the asctime() function | Supported | |
| MSC37-C | Ensure that control never reaches the end of a non-void function | Supported | |
| MSC38-C | Do not treat a predefined identifier as an object if it might only be implemented as a macro | Not supported |
|
| MSC39-C | Do not call va_arg() on a va_list that has an indeterminate value | Not supported |
|
| MSC40-C | Do not violate constraints | Not supported31 |
|
| MSC41-C | Never hard code sensitive information | Assistance provided32 | |
| WIN00-C | Be specific when dynamically loading libraries | Supported | |
| WIN01-C | Do not forcibly terminate execution | Supported | |
| WIN02-C | Restrict privileges when spawning child processes | Supported | |
| WIN03-C | Understand HANDLE inheritance | Not supported |
|
| WIN04-C | Consider encrypting function pointers | Not supported |
|
| WIN30-C | Properly pair allocation and deallocation functions | Not supported |
|
| CON01-C | Acquire and release synchronization primitives in the same module, at the same level of abstraction | Partially supported33 | |
| CON02-C | Do not use volatile as a synchronization primitive | Not supported |
|
| CON03-C | Ensure visibility when accessing shared variables | Not supported |
|
| CON04-C | Join or detach threads even if their exit status is unimportant | Not supported |
|
| CON05-C | Do not perform operations that can block while holding a lock | Not supported |
|
| CON06-C | Ensure that every mutex outlives the data it protects | Not supported |
|
| CON07-C | Ensure that compound operations on shared variables are atomic | Not supported |
|
| CON08-C | Do not assume that a group of calls to independently atomic methods is atomic | Not supported |
|
| CON09-C | Avoid the ABA problem when using lock-free algorithms | Not supported |
|
| CON30-C | Clean up thread-specific storage | Not supported |
|
| CON31-C | Do not destroy a mutex while it is locked | Not supported |
|
| CON32-C | Prevent data races when accessing bit-fields from multiple threads | Partially supported34 | |
| CON33-C | Avoid race conditions when using library functions | Supported | |
| CON34-C | Declare objects shared between threads with appropriate storage durations | Not supported |
|
| CON35-C | Avoid deadlock by locking in a predefined order | Supported | |
| CON36-C | Wrap functions that can spuriously wake up in a loop | Not supported |
|
| CON37-C | Do not call signal() in a multithreaded program | Supported | |
| CON38-C | Preserve thread safety and liveness when using condition variables | Not supported |
|
| CON39-C | Do not join or detach a thread that was previously joined or detached | Not supported |
|
| CON40-C | Do not refer to an atomic variable twice in an expression | Not supported |
|
| CON41-C | Wrap functions that can fail spuriously in a loop | Not supported |
|
| CON42-C | Don’t allow attackers to influence environment variables that control concurrency parameters | Not supported |
|
| CON43-C | Do not allow data races in multithreaded code | Partially supported35 | |
| POS01-C | Check for the existence of links when dealing with files | Not supported |
|
| POS02-C | Follow the principle of least privilege | Not supported |
|
| POS04-C | Avoid using PTHREAD_MUTEX_NORMAL type mutex locks | Supported | |
| POS05-C | Limit access to files by creating a jail | Not supported |
|
| POS30-C | Use the readlink() function properly | Not supported |
|
| POS33-C | Do not use vfork() | Supported | |
| POS34-C | Do not call putenv() with a pointer to an automatic variable as the argument | Supported | |
| POS35-C | Avoid race conditions while checking for the existence of a symbolic link | Not supported |
|
| POS36-C | Observe correct revocation order while relinquishing privileges | Not supported |
|
| POS37-C | Ensure that privilege relinquishment is successful | Not supported |
|
| POS38-C | Beware of race conditions when using fork and file descriptors | Not supported |
|
| POS39-C | Use the correct byte ordering when transferring data between systems | Not supported |
|
| POS44-C | Do not use signals to terminate threads | Supported | |
| POS47-C | Do not use threads that can be canceled asynchronously | Supported | |
| POS48-C | Do not unlock or destroy another POSIX thread’s mutex | Not supported |
|
| POS49-C | When data must be accessed by multiple threads, provide a mutex and guarantee no adjacent data is also accessed | Partially supported36 | |
| POS50-C | Declare objects shared between POSIX threads with appropriate storage durations | Not supported |
|
| POS51-C | Avoid deadlock with POSIX threads by locking in predefined order | Not supported |
|
| POS52-C | Do not perform operations that can block while holding a POSIX lock | Not supported |
|
| POS53-C | Do not use more than one mutex for concurrent waiting operations on a condition variable | Not supported |
|
| POS54-C | Detect and handle POSIX library errors | Assistance provided | |
1Reports any use of pasting or stringizing operators in a macro definition
2Does not report ‘Q’ or ‘D’ vs ‘0’ or ‘O’
3Exceptions not supported
4Reports issues involving format strings
5Reports missing body from if, for, or while with semi-colon immediately following predicate
6Reports address of function, array, or variable directly or indirectly compared to null
7Reports comparisons of Boolean values to constants other than 0
8Reports casts directly from a pointer to a less strictly aligned type to a pointer to a more strictly aligned type
9Reports structures which require padding between members or after the last member
10Reports use of the restrict keyword
11Reports use of sizeof with an expression that would have side effects
12Reports Boolean test of unparenthesized assignment
13Reports argument promotion to match prototype
14Reports data type inconsistencies in format strings
15Reports use of a bitwise operator on an expression with a signed MISRA C 2004 underlying type
16Reports bitwise not of signed quantity, declaration of named signed single-bit bitfields, and negation of the minimum negative
integer
17Reports casts from pointer types to smaller integer types which lose information
18Reports domain errors for functions with the Semantics *dom_1, *dom_lt0, or *dom_lt1, including standard library math
functions
19Conceptually includes all other ARR items which are mapped to their respective guidelines; explicit mappings for ARR00 are present
when a situation mentioned in the guideline itself is encountered
20Reports illegal conversions involving pointers to char or wchar_t as well as byte/wide-oriented stream inconsistencies
21Reports implicit conversions from void* to another type
22Reports use of variable length arrays and recursion
23Reports use of null pointers including those which could be returned when a call to an allocation function fails
24Reports non-literal format strings
25Reports when a FILE pointer is dereferenced
26Reports use of the signal function
27Reports use of null pointers including function parameters which are assumed to have the potential to be null
28Many instances of platform-dependent behavior are reported but do not include appended text citing this guideline
29Many instances of undefined behavior are reported but do not include appended text citing this guideline
30Reports functions that read passwords from the user or that take a password as an argument instead of prompting the user as well as
insecure password erasure (see also MSC41-C)
31Many constraint violations are reported as error messages but do not include appended text citing this guideline
32Reports when a literal is provided as an argument to a function parameter with the ‘noliteral’ argument Semantic; several Windows
API functions are marked as such and the ‘-sem’ option can apply it to other functions as appropriate
33Acquire and release synchronization primitives within the same scope
34Access is detected at the object level (not at the field level)
35Access is detected at the object level (not at the field level)
36Access is detected at the object level (not at the field level)