| Rule or Recommendation | Applicable to Android Application Development? | |
|---|
| Recommendations | Android app development applicable? | Comments |
| PRE00-C. Prefer inline or static functions to function-like macros | Applicable | |
| PRE01-C. Use parentheses within macros around parameter names | Applicable | |
| PRE02-C. Macro replacement lists should be parenthesized | Applicable | |
| PRE03-C. Prefer typedefs to defines for encoding types | Applicable | |
| PRE04-C. Do not reuse a standard header file name | Applicable | |
| PRE05-C. Understand macro replacement when concatenating tokens or performing stringification | Applicable | |
| PRE06-C. Enclose header files in an inclusion guard | Applicable | |
| PRE07-C. Avoid using repeated question marks | Applicable | |
| PRE08-C. Guarantee that header file names are unique | Applicable | |
| PRE09-C. Do not replace secure functions with deprecated or obsolescent functions | Applicable | |
| PRE10-C. Wrap multistatement macros in a do-while loop | Applicable | |
| PRE11-C. Do not conclude macro definitions with a semicolon | Applicable | |
| PRE12-C. Do not define unsafe macros | Applicable | |
| PRE13-C. Use the Standard predefined macros to test for versions and features. | Applicable | |
| Rules | Android app development applicable? | Comments |
| PRE30-C. Do not create a universal character name through concatenation | Applicable | |
| PRE31-C. Avoid side effects in arguments to unsafe macros | Applicable | |
| PRE32-C. Do not use preprocessor directives in invocations of function-like macros | Applicable | |
| Recommendations | Android app development applicable? | Comments |
| DCL00-C. Const-qualify immutable objects | Applicable | |
| DCL01-C. Do not reuse variable names in subscopes | Applicable | |
| DCL02-C. Use visually distinct identifiers | Applicable | |
| DCL03-C. Use a static assertion to test the value of a constant expression | Applicable | |
| DCL04-C. Do not declare more than one variable per declaration | Applicable | |
| DCL05-C. Use typedefs of non-pointer types only | Applicable | |
| DCL06-C. Use meaningful symbolic constants to represent literal values | Applicable | |
| DCL07-C. Include the appropriate type information in function declarators | Applicable | |
| DCL08-C. Properly encode relationships in constant definitions | Applicable | |
| DCL09-C. Declare functions that return errno with a return type of errno_t | Applicable | |
| DCL10-C. Maintain the contract between the writer and caller of variadic functions | Applicable | |
| DCL11-C. Understand the type issues associated with variadic functions | Applicable | |
| DCL12-C. Implement abstract data types using opaque types | Applicable | |
| DCL13-C. Declare function parameters that are pointers to values not changed by the function as const | Applicable | |
| DCL15-C. Declare file-scope objects or functions that do not need external linkage as static | Applicable | |
| DCL16-C. Use "L," not "l," to indicate a long value | Applicable | |
| DCL17-C. Beware of miscompiled volatile-qualified variables | Applicable | |
| DCL18-C. Do not begin integer constants with 0 when specifying a decimal value | Applicable | |
| DCL19-C. Minimize the scope of variables and functions | Applicable | |
| DCL20-C. Explicitly specify void when a function accepts no arguments | Applicable | |
| DCL21-C. Understand the storage of compound literals | Applicable | |
| DCL22-C. Use volatile for data that cannot be cached | Applicable | |
| DCL23-C. Guarantee that mutually visible identifiers are unique | Applicable | |
| Rules | Android app development applicable? | Comments |
| DCL30-C. Declare objects with appropriate storage durations | Applicable | |
| DCL31-C. Declare identifiers before using them | Applicable | |
| DCL36-C. Do not declare an identifier with conflicting linkage classifications | Applicable | |
| DCL37-C. Do not declare or define a reserved identifier | Applicable | |
| DCL38-C. Use the correct syntax when declaring a flexible array member | Applicable | Arrays: Need examination of Android support. (gcc support of arrays partial). Note native code array issues different with ART than with Dalvik: http://developer.android.com/guide/practices/verifying-apps-art.html#JNI_Issues |
| DCL39-C. Avoid information leakage in structure padding | Applicable | |
| DCL40-C. Do not create incompatible declarations of the same function or object | Applicable | |
| DCL41-C. Do not declare variables inside a switch statement before the first case label | Applicable | |
| Recommendations | Android app development applicable? | Comments |
| EXP00-C. Use parentheses for precedence of operation | Applicable | |
| EXP02-C. Be aware of the short-circuit behavior of the logical AND and OR operators | Applicable | |
| EXP03-C. Do not assume the size of a structure is the sum of the sizes of its members | Applicable | |
| EXP05-C. Do not cast away a const qualification | Applicable | |
| EXP07-C. Do not diminish the benefits of constants by assuming their values in expressions | Applicable | |
| EXP08-C. Ensure pointer arithmetic is used correctly | Applicable | |
| EXP09-C. Use sizeof to determine the size of a type or variable | Applicable | |
| EXP10-C. Do not depend on the order of evaluation of subexpressions or the order in which side effects take place | Applicable | |
| EXP11-C. Do not make assumptions regarding the layout of structures with bit-fields | Applicable | |
| EXP12-C. Do not ignore values returned by functions | Applicable | |
| EXP13-C. Treat relational and equality operators as if they were nonassociative | Applicable | |
| EXP14-C. Beware of integer promotion when performing bitwise operations on integer types smaller than int | Applicable | |
| EXP15-C. Do not place a semicolon on the same line as an if, for, or while statement | Applicable | |
| EXP16-C. Do not compare function pointers to constant values | Applicable | |
| EXP17-C. Do not perform bitwise operations in conditional expressions | Applicable | |
| EXP19-C. Use braces for the body of an if, for, or while statement | Applicable | |
| EXP20-C. Perform explicit tests to determine success, true and false, and equality | Applicable | |
| EXP21-C. Place constants on the left of equality comparisons | Applicable | |
| Rules | Android app development applicable? | Comments |
| EXP30-C. Do not depend on the order of evaluation for side effects | Applicable | |
| EXP32-C. Do not access a volatile object through a nonvolatile reference | Applicable | |
| EXP33-C. Do not read uninitialized memory | Applicable | |
| EXP34-C. Do not dereference null pointers | Applicable | |
| EXP35-C. Do not modify objects with temporary lifetime | ? | Possibly C11 relevant material, relevance must be considered on Android. |
| EXP36-C. Do not cast pointers into more strictly aligned pointer types | Applicable | 36C ARM chips more strict, X86 not so strict (so, relevant). |
| EXP37-C. Call functions with the correct number and type of arguments | Applicable | |
| EXP39-C. Do not access a variable through a pointer of an incompatible type | Applicable | |
| EXP40-C. Do not modify constant objects | Applicable | |
| EXP42-C. Do not compare padding data | Applicable | |
| EXP43-C. Avoid undefined behavior when using restrict-qualified pointers | Applicable | |
| EXP44-C. Do not rely on side effects in operands to sizeof, _Alignof, or _Generic | Applicable | |
| EXP45-C. Do not perform assignments in selection statements | Applicable | |
| Recommendations | Android app development applicable? | Comments |
| INT00-C. Understand the data model used by your implementation(s) | Applicable | |
| INT01-C. Use rsize_t or size_t for all integer values representing the size of an object | Applicable | |
| INT02-C. Understand integer conversion rules | Applicable | |
| INT04-C. Enforce limits on integer values originating from tainted sources | Applicable | |
| INT05-C. Do not use input functions to convert character data if they cannot handle all possible inputs | Applicable | |
| INT06-C. Use strtol() or a related function to convert a string token to an integer | Applicable | |
| INT07-C. Use only explicitly signed or unsigned char type for numeric values | Applicable | |
| INT08-C. Verify that all integer values are in range | Applicable | |
| INT09-C. Ensure enumeration constants map to unique values | Applicable | |
| INT10-C. Do not assume a positive remainder when using the % operator | Applicable | |
| INT12-C. Do not make assumptions about the type of a plain int bit-field when used in an expression | Applicable | |
| INT13-C. Use bitwise operators only on unsigned operands | Applicable | |
| INT14-C. Avoid performing bitwise and arithmetic operations on the same data | Applicable | |
| INT15-C. Use intmax_t or uintmax_t for formatted IO on programmer-defined integer types | Applicable | |
| INT16-C. Do not make assumptions about representation of signed integers | Applicable | |
| INT17-C. Define integer constants in an implementation-independent manner | Applicable | |
| INT18-C. Evaluate integer expressions in a larger size before comparing or assigning to that size | Applicable | |
| Rules | Android app development applicable? | Comments |
| INT30-C. Ensure that unsigned integer operations do not wrap | Applicable | |
| INT31-C. Ensure that integer conversions do not result in lost or misinterpreted data | Applicable | |
| INT32-C. Ensure that operations on signed integers do not result in overflow | Applicable | |
| INT33-C. Ensure that division and remainder operations do not result in divide-by-zero errors | Applicable | |
| 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 | Applicable | |
| INT35-C. Use correct integer precisions | Applicable soon | Currently may not apply; if no 64-bit Android phones (although current news says on the way) |
| INT36-C. Converting a pointer to integer or integer to pointer | ? | Don't know if a hardware platform for Android that this applies to. (only apply to certain arcane platform) |
| Recommendations | Android app development applicable? | Comments |
| FLP00-C. Understand the limitations of floating-point numbers | Applicable | |
| FLP01-C. Take care in rearranging floating-point expressions | Applicable | |
| FLP02-C. Avoid using floating-point numbers when precise computation is needed | Applicable | |
| FLP03-C. Detect and handle floating-point errors | Applicable | |
| FLP04-C. Check floating-point inputs for exceptional values | Applicable | Maybe currently, a restriction on size of ints/doubles, etc. (64 bit chips) |
| FLP05-C. Don't use denormalized numbers | Applicable | Maybe currently, a restriction on size of ints/doubles, etc. (64 bit chips) |
| FLP06-C. Convert integers to floating point for floating-point operations | Applicable | Maybe currently, a restriction on size of ints/doubles, etc. (64 bit chips) |
| FLP07-C. Cast the return value of a function that returns a floating-point type | Applicable | Maybe currently, a restriction on size of ints/doubles, etc. (64 bit chips) |
| Rules | Android app development applicable? | Comments |
| FLP30-C. Do not use floating-point variables as loop counters | Applicable | |
| FLP32-C. Prevent or detect domain and range errors in math functions | Applicable | Maybe currently, a restriction on size of ints/doubles, etc. (64 bit chips) |
| FLP34-C. Ensure that floating-point conversions are within range of the new type | Applicable | Maybe currently, a restriction on size of ints/doubles, etc. (64 bit chips) |
| FLP36-C. Preserve precision when converting integral values to floating-point type | Applicable | Maybe currently, a restriction on size of ints/doubles, etc. (64 bit chips) |
| Recommendations | Android app development applicable? | Comments |
| ARR00-C. Understand how arrays work | ? | Arrays: Need examination of Android support. (gcc support of arrays partial). Note native code array issues different with ART than with Dalvik: http://developer.android.com/guide/practices/verifying-apps-art.html#JNI_Issues |
| ARR01-C. Do not apply the sizeof operator to a pointer when taking the size of an array | ? | Arrays: Need examination of Android support. (gcc support of arrays partial). Note native code array issues different with ART than with Dalvik: http://developer.android.com/guide/practices/verifying-apps-art.html#JNI_Issues |
| ARR02-C. Explicitly specify array bounds, even if implicitly defined by an initializer | ? | Arrays: Need examination of Android support. (gcc support of arrays partial). Note native code array issues different with ART than with Dalvik: http://developer.android.com/guide/practices/verifying-apps-art.html#JNI_Issues |
| Rules | Android app development applicable? | Comments |
| ARR30-C. Do not form or use out-of-bounds pointers or array subscripts | ? | Arrays: Need examination of Android support. (gcc support of arrays partial). Note native code array issues different with ART than with Dalvik: http://developer.android.com/guide/practices/verifying-apps-art.html#JNI_Issues |
| ARR32-C. Ensure size arguments for variable length arrays are in a valid range | ? | Arrays: Need examination of Android support. (gcc support of arrays partial). Note native code array issues different with ART than with Dalvik: http://developer.android.com/guide/practices/verifying-apps-art.html#JNI_Issues |
| ARR36-C. Do not subtract or compare two pointers that do not refer to the same array | ? | Arrays: Need examination of Android support. (gcc support of arrays partial). Note native code array issues different with ART than with Dalvik: http://developer.android.com/guide/practices/verifying-apps-art.html#JNI_Issues |
| ARR37-C. Do not add or subtract an integer to a pointer to a non-array object | ? | Arrays: Need examination of Android support. (gcc support of arrays partial). Note native code array issues different with ART than with Dalvik: http://developer.android.com/guide/practices/verifying-apps-art.html#JNI_Issues |
| ARR38-C. Guarantee that library functions do not form invalid pointers | ? | Arrays: Need examination of Android support. (gcc support of arrays partial). Note native code array issues different with ART than with Dalvik: http://developer.android.com/guide/practices/verifying-apps-art.html#JNI_Issues |
| ARR39-C. Do not add or subtract a scaled integer to a pointer | ? | Arrays: Need examination of Android support. (gcc support of arrays partial). Note native code array issues different with ART than with Dalvik: http://developer.android.com/guide/practices/verifying-apps-art.html#JNI_Issues |
| Recommendations | Android app development applicable? | Comments |
| STR00-C. Represent characters using an appropriate type | Applicable | |
| STR01-C. Adopt and implement a consistent plan for managing strings | Applicable | |
| STR02-C. Sanitize data passed to complex subsystems | Applicable | |
| STR03-C. Do not inadvertently truncate a string | Applicable | |
| STR04-C. Use plain char for characters in the basic character set | Applicable | |
| STR05-C. Use pointers to const when referring to string literals | Applicable | |
| STR06-C. Do not assume that strtok() leaves the parse string unchanged | Applicable | |
| STR07-C. Use the bounds-checking interfaces for remediation of existing string manipulation code | Applicable | |
| STR08-C. Use managed strings for development of new string manipulation code | Applicable | |
| STR09-C. Don't assume numeric values for expressions with type plain character | Applicable | |
| STR10-C. Do not concatenate different type of string literals | Applicable | |
| STR11-C. Do not specify the bound of a character array initialized with a string literal | Applicable | Arrays: Need examination of Android support. (gcc support of arrays partial). Note native code array issues different with ART than with Dalvik: http://developer.android.com/guide/practices/verifying-apps-art.html#JNI_Issues |
| Rules | Android app development applicable? | Comments |
| STR30-C. Do not attempt to modify string literals | Applicable | STR: rest, yes |
| STR31-C. Guarantee that storage for strings has sufficient space for character data and the null terminator | Applicable | STR: rest, yes |
| STR32-C. Do not pass a non-null-terminated character sequence to a library function that expects a string | Applicable | |
| STR34-C. Cast characters to unsigned char before converting to larger integer sizes | ? | Can chars be unsigned on Android? Might be a compiler option, so yes. Not needed for new code, but might have previous code affected by it. |
| STR37-C. Arguments to character-handling functions must be representable as an unsigned char | Applicable | |
| STR38-C. Do not confuse narrow and wide character strings and functions | ? | Not sure, needs more investigation. |
| Recommendations | Android app development applicable? | Comments |
| MEM00-C. Allocate and free memory in the same module, at the same level of abstraction | Applicable | |
| MEM01-C. Store a new value in pointers immediately after free() | Applicable | |
| MEM02-C. Immediately cast the result of a memory allocation function call into a pointer to the allocated type | Applicable | |
| MEM03-C. Clear sensitive information stored in reusable resources | Applicable | |
| MEM04-C. Beware of zero-length allocations | Applicable | |
| MEM05-C. Avoid large stack allocations | Applicable | |
| MEM06-C. Ensure that sensitive data is not written out to disk | Applicable | |
| MEM07-C. Ensure that the arguments to calloc(), when multiplied, do not wrap | Applicable | |
| MEM10-C. Define and use a pointer validation function | Applicable | |
| MEM11-C. Do not assume infinite heap space | Applicable | |
| MEM12-C. Consider using a goto chain when leaving a function on error when using and releasing resources | Applicable | |
| Rules | Android app development applicable? | Comments |
| MEM30-C. Do not access freed memory | Applicable | |
| MEM31-C. Free dynamically allocated memory when no longer needed | Applicable | |
| MEM33-C. Allocate and copy structures containing a flexible array member dynamically | Applicable | Arrays: Need examination of Android support. (gcc support of arrays partial). Note native code array issues different with ART than with Dalvik: http://developer.android.com/guide/practices/verifying-apps-art.html#JNI_Issues |
| MEM34-C. Only free memory allocated dynamically | Applicable | |
| MEM35-C. Allocate sufficient memory for an object | Applicable | |
| MEM36-C. Do not modify the alignment of objects by calling realloc() | Applicable | |
| Recommendations | Android app development applicable? | Comments |
| FIO01-C. Be careful using functions that use file names for identification | ? | |
| FIO02-C. Canonicalize path names originating from tainted sources | ? | |
| FIO03-C. Do not make assumptions about fopen() and file creation | ? | |
| FIO05-C. Identify files using multiple file attributes | ? | |
| FIO06-C. Create files with appropriate access permissions | ? | |
| FIO08-C. Take care when calling remove() on an open file | ? | |
| FIO09-C. Be careful with binary data when transferring data across systems | ? | |
| FIO10-C. Take care when using the rename() function | ? | |
| FIO11-C. Take care when specifying the mode parameter of fopen() | ? | |
| FIO13-C. Never push back anything other than one read character | ? | |
| FIO14-C. Understand the difference between text mode and binary mode with file streams | ? | |
| FIO15-C. Ensure that file operations are performed in a secure directory | ? | FIO15-C: Look at Android/C interactions more closely to see if applicable. |
| FIO17-C. Do not rely on an ending null character when using fread() | ? | |
| FIO18-C. Never expect fwrite() to terminate the writing process at a null character | ? | |
| FIO19-C. Do not use fseek() and ftell() to compute the size of a regular file | ? | |
| FIO20-C. Avoid unintentional truncation when using fgets() or fgetws() | ? | |
| FIO21-C. Do not create temporary files in shared directories | ? | |
| FIO22-C. Close files before spawning processes | ? | |
| FIO23-C. Do not exit with unflushed data in stdout or stderr | ? | |
| Rules | Android app development applicable? | Comments |
| FIO30-C. Exclude user input from format strings | Applicable | Universal |
| FIO31-C. Do not open a file that is already open | ? | |
| FIO32-C. Do not perform operations on devices that are only appropriate for files | ? | |
| FIO34-C. Distinguish between characters read from a file and EOF or WEOF | ? | EOF/WEOF: Only apply to app's public files? Others protected by VM? |
| FIO37-C. Do not assume that fgets() or fgetws() returns a nonempty string when successful | ? | |
| FIO38-C. Do not copy a FILE object | ? | FIO reference. What is Android filesystem? http://stackoverflow.com/questions/2421826/what-is-androids-file-system It depends on what filesystem, for example /system and /data are yaffs2 while /sdcard is vfat By default, it uses YAFFS - Yet Another Flash File System. Depends on what hardware/platform you use. Since Android uses the Linux-kernel at this level, it is more or less possible to use whatever filesystem the Linux-kernel supports. But since most phones use some kind of nand flash, it is safe to assume that they use YAFFS. But please note that if some vendor wants to sell a Android netbook (with a harddrive), they could use ext3 or something like that. |
| FIO39-C. Do not alternately input and output from a stream without an intervening flush or positioning call | ? | |
| FIO40-C. Reset strings on fgets() or fgetws() failure | ? | |
| FIO41-C. Do not call getc(), putc(), getwc(), or putwc() with a stream argument that has side effects | ? | |
| FIO42-C. Close files when they are no longer needed | ? | |
| FIO44-C. Only use values for fsetpos() that are returned from fgetpos() | ? | |
| FIO45-C. Avoid TOCTOU race conditions while accessing files | ? | |
| FIO46-C. Do not access a closed file | ? | |
| FIO47-C. Use valid format strings | Applicable | Universal |
| Recommendations | Android app development applicable? | Comments |
| ENV01-C. Do not make assumptions about the size of an environment variable | Applicable | |
| ENV02-C. Beware of multiple environment variables with the same effective name | Applicable | |
| ENV03-C. Sanitize the environment when invoking external programs | Applicable | |
| Rules | Android app development applicable? | Comments |
| ENV30-C. Do not modify the object referenced by the return value of certain functions | Applicable | |
| ENV31-C. Do not rely on an environment pointer following an operation that may invalidate it | Applicable | |
| ENV32-C. All exit handlers must return normally | Applicable | |
| ENV33-C. Do not call system() | Applicable | |
| ENV34-C. Do not store pointers returned by certain functions | Applicable | |
| Recommendations | Android app development applicable? | Comments |
| SIG00-C. Mask signals handled by noninterruptible signal handlers | Applicable | SigAction may solve these problems. If Android supports SigAction, these rules/recommendations may not be needed. http://stackoverflow.com/questions/7245550/android-app-restarts-automatically-after-a-crash |
| SIG01-C. Understand implementation-specific details regarding signal handler persistence | Applicable | SigAction may solve these problems. If Android supports SigAction, these rules/recommendations may not be needed. http://stackoverflow.com/questions/7245550/android-app-restarts-automatically-after-a-crash |
| SIG02-C. Avoid using signals to implement normal functionality | Applicable | SigAction may solve these problems. If Android supports SigAction, these rules/recommendations may not be needed. http://stackoverflow.com/questions/7245550/android-app-restarts-automatically-after-a-crash |
| Rules | Android app development applicable? | Comments |
| SIG30-C. Call only asynchronous-safe functions within signal handlers | Applicable | SigAction may solve these problems. If Android supports SigAction, these rules/recommendations may not be needed. http://stackoverflow.com/questions/7245550/android-app-restarts-automatically-after-a-crash |
| SIG31-C. Do not access shared objects in signal handlers | Applicable | SigAction may solve these problems. If Android supports SigAction, these rules/recommendations may not be needed. http://stackoverflow.com/questions/7245550/android-app-restarts-automatically-after-a-crash |
| SIG34-C. Do not call signal() from within interruptible signal handlers | Applicable | SigAction may solve these problems. If Android supports SigAction, these rules/recommendations may not be needed. http://stackoverflow.com/questions/7245550/android-app-restarts-automatically-after-a-crash |
| SIG35-C. Do not return from a computational exception signal handler | Applicable | SigAction may solve these problems. If Android supports SigAction, these rules/recommendations may not be needed. http://stackoverflow.com/questions/7245550/android-app-restarts-automatically-after-a-crash |
| Recommendations | Android app development applicable? | Comments |
| ERR00-C. Adopt and implement a consistent and comprehensive error-handling policy | Applicable | |
| ERR01-C. Use ferror() rather than errno to check for FILE stream errors | Applicable | |
| ERR02-C. Avoid in-band error indicators | Applicable | |
| ERR03-C. Use runtime-constraint handlers when calling the bounds-checking interfaces | Applicable | |
| ERR04-C. Choose an appropriate termination strategy | Applicable | |
| ERR05-C. Application-independent code should provide error detection without dictating error handling | Applicable | |
| ERR06-C. Understand the termination behavior of assert() and abort() | Applicable | |
| ERR07-C. Prefer functions that support error checking over equivalent functions that don't | Applicable | |
| Rules | Android app development applicable? | Comments |
| 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 | Applicable | |
| ERR32-C. Do not rely on indeterminate values of errno | Applicable | |
| ERR33-C. Detect and handle standard library errors | Applicable | |
| Recommendations | Android app development applicable? | Comments |
| API00-C. Functions should validate their parameters | Applicable | |
| API01-C. Avoid laying out strings in memory directly before sensitive data | ? | |
| API02-C. Functions that read or write to or from an array should take an argument to specify the source or target size | Applicable | Arrays: Need examination of Android support. (gcc support of arrays partial). Note native code array issues different with ART than with Dalvik: http://developer.android.com/guide/practices/verifying-apps-art.html#JNI_Issues |
| API03-C. Create consistent interfaces and capabilities across related functions | Applicable | |
| API04-C. Provide a consistent and usable error-checking mechanism | Applicable | |
| API05-C. Use conformant array parameters | Applicable | Arrays: Need examination of Android support. (gcc support of arrays partial). Note native code array issues different with ART than with Dalvik: http://developer.android.com/guide/practices/verifying-apps-art.html#JNI_Issues |
| API07-C. Enforce type safety | Applicable | |
| API08-C. Avoid parameter names in a function prototype | Applicable | |
| API09-C. Compatible values should have the same type | ? | |
| Recommendations | Android app development applicable? | Comments |
| CON00-C. Avoid race conditions with multiple threads | ? | CON concurrency: Need to look into Android, does it support C11? Look at specifics of Android. Maybe POSIX threads, not C11 threads. |
| CON01-C. Acquire and release synchronization primitives in the same module, at the same level of abstraction | ? | CON concurrency: Need to look into Android, does it support C11? Look at specifics of Android. Maybe POSIX threads, not C11 threads. |
| CON02-C. Do not use volatile as a synchronization primitive | ? | CON concurrency: Need to look into Android, does it support C11? Look at specifics of Android. Maybe POSIX threads, not C11 threads. |
| CON03-C. Ensure visibility when accessing shared variables | ? | CON concurrency: Need to look into Android, does it support C11? Look at specifics of Android. Maybe POSIX threads, not C11 threads. |
| CON04-C. Join or detach threads even if their exit status is unimportant | ? | CON concurrency: Need to look into Android, does it support C11? Look at specifics of Android. Maybe POSIX threads, not C11 threads. |
| CON05-C. Do not perform operations that can block while holding a lock | ? | CON concurrency: Need to look into Android, does it support C11? Look at specifics of Android. Maybe POSIX threads, not C11 threads. |
| CON06-C. Ensure that every mutex outlives the data it protects | ? | CON concurrency: Need to look into Android, does it support C11? Look at specifics of Android. Maybe POSIX threads, not C11 threads. |
| CON07-C. Ensure that compound operations on shared variables are atomic | ? | CON concurrency: Need to look into Android, does it support C11? Look at specifics of Android. Maybe POSIX threads, not C11 threads. |
| CON08-C. Do not assume that a group of calls to independently atomic methods is atomic | ? | CON concurrency: Need to look into Android, does it support C11? Look at specifics of Android. Maybe POSIX threads, not C11 threads. |
| CON09-C. Avoid the ABA problem when using lock-free algorithms | ? | CON concurrency: Need to look into Android, does it support C11? Look at specifics of Android. Maybe POSIX threads, not C11 threads. |
| Rules | Android app development applicable? | Comments |
| CON30-C. Clean up thread-specific storage | ? | CON concurrency: Need to look into Android, does it support C11? Look at specifics of Android. Maybe POSIX threads, not C11 threads. |
| CON31-C. Do not destroy a mutex while it is locked | ? | CON concurrency: Need to look into Android, does it support C11? Look at specifics of Android. Maybe POSIX threads, not C11 threads. |
| CON32-C. Prevent data races when accessing bit-fields from multiple threads | ? | CON concurrency: Need to look into Android, does it support C11? Look at specifics of Android. Maybe POSIX threads, not C11 threads. |
| CON33-C. Avoid race conditions when using library functions | ? | CON concurrency: Need to look into Android, does it support C11? Look at specifics of Android. Maybe POSIX threads, not C11 threads. |
| CON34-C. Declare objects shared between threads with appropriate storage durations | ? | CON concurrency: Need to look into Android, does it support C11? Look at specifics of Android. Maybe POSIX threads, not C11 threads. |
| CON35-C. Avoid deadlock by locking in a predefined order | ? | CON concurrency: Need to look into Android, does it support C11? Look at specifics of Android. Maybe POSIX threads, not C11 threads. |
| CON36-C. Wrap functions that can spuriously wake up in a loop | ? | CON concurrency: Need to look into Android, does it support C11? Look at specifics of Android. Maybe POSIX threads, not C11 threads. |
| CON37-C. Do not call signal() in a multithreaded program | ? | CON concurrency: Need to look into Android, does it support C11? Look at specifics of Android. Maybe POSIX threads, not C11 threads. |
| CON38-C. Preserve thread safety and liveness when using condition variables | ? | CON concurrency: Need to look into Android, does it support C11? Look at specifics of Android. Maybe POSIX threads, not C11 threads. |
| CON39-C. Do not join or detach a thread that was previously joined or detached | ? | CON concurrency: Need to look into Android, does it support C11? Look at specifics of Android. Maybe POSIX threads, not C11 threads. |
| CON40-C. Do not refer to an atomic variable twice in an expression | ? | CON concurrency: Need to look into Android, does it support C11? Look at specifics of Android. Maybe POSIX threads, not C11 threads. |
| CON41-C. Wrap functions that can fail spuriously in a loop | ? | CON concurrency: Need to look into Android, does it support C11? Look at specifics of Android. Maybe POSIX threads, not C11 threads. |
| Recommendations | Android app development applicable? | Comments |
| MSC00-C. Compile cleanly at high warning levels | Applicable | |
| MSC01-C. Strive for logical completeness | Applicable | |
| MSC04-C. Use comments consistently and in a readable fashion | Applicable | |
| MSC05-C. Do not manipulate time_t typed values directly | Applicable | |
| MSC06-C. Beware of compiler optimizations | Applicable | |
| MSC07-C. Detect and remove dead code | Applicable | |
| MSC09-C. Character encoding: Use subset of ASCII for safety | Applicable | |
| MSC10-C. Character encoding: UTF8-related issues | Applicable | |
| MSC11-C. Incorporate diagnostic tests using assertions | Applicable | |
| MSC12-C. Detect and remove code that has no effect | Applicable | |
| MSC13-C. Detect and remove unused values | Applicable | |
| MSC14-C. Do not introduce unnecessary platform dependencies | Applicable | |
| MSC15-C. Do not depend on undefined behavior | Applicable | |
| MSC17-C. Finish every set of statements associated with a case label with a break statement | Applicable | |
| MSC18-C. Be careful while handling sensitive data, such as passwords, in program code | Applicable | |
| MSC19-C. For functions that return an array, prefer returning an empty array over a null value | Applicable | Arrays: Need examination of Android support. (gcc support of arrays partial). Note native code array issues different with ART than with Dalvik: http://developer.android.com/guide/practices/verifying-apps-art.html#JNI_Issues |
| MSC20-C. Do not use a switch statement to transfer control into a complex block | Applicable | |
| MSC21-C. Use robust loop termination conditions | Applicable | |
| MSC22-C. Use the setjmp(), longjmp() facility securely | Applicable | |
| MSC23-C. Beware of vendor-specific library and language differences | Applicable | |
| MSC24-C. Do not use deprecated or obsolescent functions | Applicable | |
| Rules | Android app development applicable? | Comments |
| MSC30-C. Do not use the rand() function for generating pseudorandom numbers | Applicable | |
| MSC32-C. Properly seed pseudorandom number generators | Applicable | |
| MSC33-C. Do not pass invalid data to the asctime() function | Applicable | |
| MSC37-C. Ensure that control never reaches the end of a non-void function | Applicable | |
| MSC38-C. Do not treat a predefined identifier as an object if it might only be implemented as a macro | Applicable | |
| MSC39-C. Do not call va_arg() on a va_list that has an indeterminate value | Applicable | |
| MSC40-C. Do not violate constraints | Applicable | |
| Recommendations | Android app development applicable? | Comments |
| POS01-C. Check for the existence of links when dealing with files | ? | |
| POS02-C. Follow the principle of least privilege | Applicable | |
| POS04-C. Avoid using PTHREAD_MUTEX_NORMAL type mutex locks | ? | |
| POS05-C. Limit access to files by creating a jail | ? | |
| Rules | Android app development applicable? | Comments |
| POS30-C. Use the readlink() function properly | ? | |
| POS33-C. Do not use vfork() | ? | |
| POS34-C. Do not call putenv() with a pointer to an automatic variable as the argument | ? | |
| POS35-C. Avoid race conditions while checking for the existence of a symbolic link | ? | Can apps get root? Can they run a shell? These rules/guidelines are not meant to address rooted devices (different OS than standard Android) |
| POS36-C. Observe correct revocation order while relinquishing privileges | ? | Can apps get root? Can they run a shell? These rules/guidelines are not meant to address rooted devices (different OS than standard Android) |
| POS37-C. Ensure that privilege relinquishment is successful | ? | Can apps get root? Can they run a shell? These rules/guidelines are not meant to address rooted devices (different OS than standard Android) |
| POS38-C. Beware of race conditions when using fork and file descriptors | ? | |
| POS39-C. Use the correct byte ordering when transferring data between systems | ? | |
| POS44-C. Do not use signals to terminate threads | ? | Further investigation needed, specific to SigAction |
| POS47-C. Do not use threads that can be canceled asynchronously | ? | |
| POS48-C. Do not unlock or destroy another POSIX thread's mutex | ? | |
| POS49-C. When data must be accessed by multiple threads, provide a mutex and guarantee no adjacent data is also accessed | ? | Look into Android specifics for this, regarding "guarantee no adjacent data is accessed". |
| POS50-C. Declare objects shared between POSIX threads with appropriate storage durations | ? | |
| POS51-C. Avoid deadlock with POSIX threads by locking in predefined order | ? | |
| POS52-C. Do not perform operations that can block while holding a POSIX lock | ? | |
| POS53-C. Do not use more than one mutex for concurrent waiting operations on a condition variable | ? | |
| POS54-C. Detect and handle POSIX library errors | ? | |
| Recommendations | Android app development applicable? | Comments |
| WIN00-C. Be specific when dynamically loading libraries | Not applicable | Android apps are not used in a Microsoft environment |
| WIN01-C. Do not forcibly terminate execution | Not applicable | Android apps are not used in a Microsoft environment |
| WIN02-C. Restrict privileges when spawning child processes | Not applicable | Android apps are not used in a Microsoft environment |
| WIN03-C. Understand HANDLE inheritance | Not applicable | Android apps are not used in a Microsoft environment |
| WIN04-C. Consider encrypting function pointers | Not applicable | Android apps are not used in a Microsoft environment |
| Rules | Android app development applicable? | Comments |
| WIN30-C. Properly pair allocation and deallocation functions | Not applicable | Android apps are not used in a Microsoft environment |
