You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 89 Next »

The following table lists the CERT C Coding Standard rules and recommendations, and states their applicability to the development of Android applications. Applicable means that the rule can be applied to general C platforms including Android. Applicable? means that one reviewer found the rule to be applicable to the Android platform, but we are waiting for that to be verified. Applicable in principle means that the rule can be applied to Android but the examples currently shown in the rule are not yet relevant to Android. Not applicable means that the rule cannot be applied to Android platforms. A '?' indicates that applicability has not yet been determined.

 

RulesAndroid app development applicable?Comments
DCL38-C. Use the correct syntax when declaring a flexible array memberApplicable in Principle 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 
EXP35-C. Do not modify objects with temporary lifetimeApplicable in PrinciplePossibly C11 relevant material, relevance must be considered on Android.
EXP36-C. Do not cast pointers into more strictly aligned pointer typesApplicable in Principle36C ARM chips more strict, X86 not so strict (so, relevant). 
INT35-C. Use correct integer precisionsApplicable in PrincipleCurrently 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 pointerApplicable in PrincipleDon't know if a hardware platform for Android that this applies to. (only   apply to certain arcane platform)
FLP32-C. Prevent or detect domain and range errors in math functionsApplicable in PrincipleMaybe 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 typeApplicable in PrincipleMaybe currently, a restriction on size of ints/doubles, etc. (64 bit   chips)
FLP36-C. Preserve precision when converting integral values to floating-point typeApplicable in PrincipleMaybe currently, a restriction on size of ints/doubles, etc. (64 bit   chips)
STR30-C. Do not attempt to modify string literalsApplicable in PrincipleSTR: rest, yes
STR31-C. Guarantee that storage for strings has sufficient space for character data and the null terminatorApplicable in PrincipleSTR: rest, yes
STR34-C. Cast characters to unsigned char before converting to larger integer sizesApplicable in PrincipleCan 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.
STR38-C. Do not confuse narrow and wide character strings and functionsApplicable in PrincipleNot sure, needs more investigation.
RecommendationsAndroid app development applicable?Comments
FLP04-C. Check floating-point inputs for exceptional valuesApplicable in PrincipleMaybe currently, a restriction on size of ints/doubles, etc. (64 bit   chips)
FLP05-C. Don't use denormalized numbersApplicable in PrincipleMaybe currently, a restriction on size of ints/doubles, etc. (64 bit   chips)
FLP06-C. Convert integers to floating point for floating-point operationsApplicable in PrincipleMaybe 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 typeApplicable in PrincipleMaybe currently, a restriction on size of ints/doubles, etc. (64 bit   chips)
ARR00-C. Understand how arrays workApplicable in PrincipleArrays: 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 arrayApplicable in PrincipleArrays: 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 initializerApplicable in PrincipleArrays: 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 
ARR30-C. Do not form or use out-of-bounds pointers or array subscriptsApplicable in PrincipleArrays: 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 rangeApplicable in PrincipleArrays: 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 arrayApplicable in PrincipleArrays: 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 objectApplicable in PrincipleArrays: 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 pointersApplicable in PrincipleArrays: 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 pointerApplicable in PrincipleArrays: 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 
STR11-C. Do not specify the bound of a character array initialized with a string literalApplicable in Principle 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 
   
RulesAndroid app development applicable?Comments
MEM30-C.   Do not access freed memoryApplicable 
MEM31-C.   Free dynamically allocated memory when no longer neededApplicable 
MEM33-C.   Allocate and copy structures containing a flexible array member dynamicallyApplicable in Principle 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 dynamicallyApplicable 
MEM35-C.   Allocate sufficient memory for an objectApplicable 
MEM36-C.   Do not modify the alignment of objects by calling realloc()Applicable 
RecommendationsAndroid app development applicable?Comments
FIO01-C.   Be careful using functions that use file names for identificationApplicable in Principle 
FIO02-C.   Canonicalize path names originating from tainted sourcesApplicable in Principle 
FIO03-C.   Do not make assumptions about fopen() and file creationApplicable in Principle 
FIO05-C.   Identify files using multiple file attributesApplicable in Principle 
FIO06-C.   Create files with appropriate access permissionsApplicable in Principle 
FIO08-C.   Take care when calling remove() on an open fileApplicable in Principle 
FIO09-C.   Be careful with binary data when transferring data across systemsApplicable in Principle 
FIO10-C.   Take care when using the rename() functionApplicable in Principle 
FIO11-C.   Take care when specifying the mode parameter of fopen()Applicable in Principle 
FIO13-C.   Never push back anything other than one read characterApplicable in Principle 
FIO14-C.   Understand the difference between text mode and binary mode with file streamsApplicable in Principle 
FIO15-C.   Ensure that file operations are performed in a secure directoryApplicable in PrincipleFIO15-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()Applicable in Principle 
FIO18-C.   Never expect fwrite() to terminate the writing process at a null characterApplicable in Principle 
FIO19-C.   Do not use fseek() and ftell() to compute the size of a regular fileApplicable in Principle 
FIO20-C.   Avoid unintentional truncation when using fgets() or fgetws()Applicable in Principle 
FIO21-C.   Do not create temporary files in shared directoriesApplicable in Principle 
FIO22-C.   Close files before spawning processesApplicable in Principle 
FIO23-C.   Do not exit with unflushed data in stdout or stderrApplicable in Principle 
RulesAndroid app development applicable?Comments
FIO30-C.   Exclude user input from format stringsApplicable in PrincipleUniversal
FIO31-C.   Do not open a file that is already openApplicable in Principle 
FIO32-C.   Do not perform operations on devices that are only appropriate for filesApplicable in Principle 
FIO34-C.   Distinguish between characters read from a file and EOF or WEOFApplicable in PrincipleEOF/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   successfulApplicable in Principle 
FIO38-C.   Do not copy a FILE objectApplicable in PrincipleFIO 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 callApplicable in Principle 
FIO40-C.   Reset strings on fgets() or fgetws() failureApplicable in Principle 
FIO41-C.   Do not call getc(), putc(), getwc(), or putwc() with a stream argument that   has side effectsApplicable in Principle 
FIO42-C.   Close files when they are no longer neededApplicable in Principle 
FIO44-C.   Only use values for fsetpos() that are returned from fgetpos()Applicable in Principle 
FIO45-C.   Avoid TOCTOU race conditions while accessing filesApplicable in Principle 
FIO46-C.   Do not access a closed fileApplicable in Principle 
FIO47-C.   Use valid format stringsApplicable in PrincipleUniversal
RecommendationsAndroid app development applicable?Comments
ENV01-C.   Do not make assumptions about the size of an environment variableApplicable 
ENV02-C.   Beware of multiple environment variables with the same effective nameApplicable 
ENV03-C.   Sanitize the environment when invoking external programsApplicable 
RulesAndroid app development applicable?Comments
ENV30-C.   Do not modify the object referenced by the return value of certain functionsApplicable 
ENV31-C.   Do not rely on an environment pointer following an operation that may   invalidate itApplicable 
ENV32-C.   All exit handlers must return normallyApplicable 
ENV33-C.   Do not call system()Applicable 
ENV34-C.   Do not store pointers returned by certain functionsApplicable 
RecommendationsAndroid app development applicable?Comments
SIG00-C.   Mask signals handled by noninterruptible signal handlersApplicable in PrincipleSigAction 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   persistenceApplicable in PrincipleSigAction 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 functionalityApplicable in PrincipleSigAction 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
RulesAndroid app development applicable?Comments
SIG30-C.   Call only asynchronous-safe functions within signal handlersApplicable in PrincipleSigAction 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 handlersApplicable in PrincipleSigAction 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 handlersApplicable in PrincipleSigAction 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 handlerApplicable in PrincipleSigAction 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
RecommendationsAndroid app development applicable?Comments
ERR00-C.   Adopt and implement a consistent and comprehensive error-handling policyApplicable 
ERR01-C.   Use ferror() rather than errno to check for FILE stream errorsApplicable 
ERR02-C.   Avoid in-band error indicatorsApplicable 
ERR03-C.   Use runtime-constraint handlers when calling the bounds-checking interfacesApplicable 
ERR04-C.   Choose an appropriate termination strategyApplicable 
ERR05-C.   Application-independent code should provide error detection without dictating   error handlingApplicable 
ERR06-C.   Understand the termination behavior of assert() and abort()Applicable 
ERR07-C.   Prefer functions that support error checking over equivalent functions that   don'tApplicable 
RulesAndroid 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 failureApplicable 
ERR32-C.   Do not rely on indeterminate values of errnoApplicable 
ERR33-C.   Detect and handle standard library errorsApplicable 
RecommendationsAndroid app development applicable?Comments
API00-C.   Functions should validate their parametersApplicable 
API01-C.   Avoid laying out strings in memory directly before sensitive dataApplicable in Principle 
API02-C.   Functions that read or write to or from an array should take an argument to   specify the source or target sizeApplicable in Principle 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 functionsApplicable 
API04-C.   Provide a consistent and usable error-checking mechanismApplicable 
API05-C.   Use conformant array parametersApplicable in Principle 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 safetyApplicable 
API08-C.   Avoid parameter names in a function prototypeApplicable 
API09-C.   Compatible values should have the same typeApplicable in Principle 
RecommendationsAndroid app development applicable?Comments
CON00-C.   Avoid race conditions with multiple threadsApplicable in PrincipleCON 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 abstractionApplicable in PrincipleCON 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 primitiveApplicable in PrincipleCON 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 variablesApplicable in PrincipleCON 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 unimportantApplicable in PrincipleCON 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 lockApplicable in PrincipleCON 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 protectsApplicable in PrincipleCON 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 atomicApplicable in PrincipleCON 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 atomicApplicable in PrincipleCON 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 algorithmsApplicable in PrincipleCON concurrency: Need to look into Android, does it support C11? Look at   specifics of Android. Maybe POSIX threads, not C11 threads.
RulesAndroid app development applicable?Comments
CON30-C.   Clean up thread-specific storageApplicable in PrincipleCON 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 lockedApplicable in PrincipleCON 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 threadsApplicable in PrincipleCON 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 functionsApplicable in PrincipleCON 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 durationsApplicable in PrincipleCON 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 orderApplicable in PrincipleCON 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 loopApplicable in PrincipleCON 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 programApplicable in PrincipleCON 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 variablesApplicable in PrincipleCON 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 detachedApplicable in PrincipleCON 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 expressionApplicable in PrincipleCON 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 loopApplicable in PrincipleCON concurrency: Need to look into Android, does it support C11? Look at   specifics of Android. Maybe POSIX threads, not C11 threads.
RecommendationsAndroid app development applicable?Comments
MSC00-C.   Compile cleanly at high warning levelsApplicable 
MSC01-C.   Strive for logical completenessApplicable 
MSC04-C.   Use comments consistently and in a readable fashionApplicable 
MSC05-C.   Do not manipulate time_t typed values directlyApplicable 
MSC06-C.   Beware of compiler optimizationsApplicable 
MSC07-C.   Detect and remove dead codeApplicable 
MSC09-C.   Character encoding: Use subset of ASCII for safetyApplicable 
MSC10-C.   Character encoding: UTF8-related issuesApplicable 
MSC11-C.   Incorporate diagnostic tests using assertionsApplicable 
MSC12-C.   Detect and remove code that has no effectApplicable 
MSC13-C.   Detect and remove unused valuesApplicable 
MSC14-C.   Do not introduce unnecessary platform dependenciesApplicable 
MSC15-C.   Do not depend on undefined behaviorApplicable 
MSC17-C.   Finish every set of statements associated with a case label with a break   statementApplicable 
MSC18-C.   Be careful while handling sensitive data, such as passwords, in program codeApplicable 
MSC19-C.   For functions that return an array, prefer returning an empty array over a null valueApplicable in Principle 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 blockApplicable 
MSC21-C.   Use robust loop termination conditionsApplicable 
MSC22-C.   Use the setjmp(), longjmp() facility securelyApplicable 
MSC23-C.   Beware of vendor-specific library and language differencesApplicable 
MSC24-C.   Do not use deprecated or obsolescent functionsApplicable 
RulesAndroid app development applicable?Comments
MSC30-C.   Do not use the rand() function for generating pseudorandom numbersApplicable 
MSC32-C.   Properly seed pseudorandom number generatorsApplicable 
MSC33-C.   Do not pass invalid data to the asctime() functionApplicable 
MSC37-C.   Ensure that control never reaches the end of a non-void functionApplicable 
MSC38-C.   Do not treat a predefined identifier as an object if it might only be   implemented as a macroApplicable 
MSC39-C.   Do not call va_arg() on a va_list that has an indeterminate valueApplicable 
MSC40-C.   Do not violate constraintsApplicable 
RecommendationsAndroid app development applicable?Comments
POS01-C.   Check for the existence of links when dealing with filesApplicable in Principle 
POS02-C.   Follow the principle of least privilegeApplicable 
POS04-C.   Avoid using PTHREAD_MUTEX_NORMAL type mutex locksApplicable in Principle 
POS05-C.   Limit access to files by creating a jailApplicable in Principle 
RulesAndroid app development applicable?Comments
POS30-C.   Use the readlink() function properlyApplicable in Principle 
POS33-C.   Do not use vfork()Possibly Applicable 
POS34-C.   Do not call putenv() with a pointer to an automatic variable as the argumentPossibly Applicable 
POS35-C.   Avoid race conditions while checking for the existence of a symbolic linkApplicable in PrincipleCan 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 privilegesApplicable in PrincipleCan 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 successfulApplicable in PrincipleCan 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 descriptorsApplicable in Principle 
POS39-C.   Use the correct byte ordering when transferring data between systemsApplicable in Principle 
POS44-C.   Do not use signals to terminate threadsApplicable in PrincipleFurther investigation needed, specific to SigAction
POS47-C.   Do not use threads that can be canceled asynchronouslyApplicable in Principle 
POS48-C.   Do not unlock or destroy another POSIX thread's mutexApplicable in Principle 
POS49-C.   When data must be accessed by multiple threads, provide a mutex and guarantee   no adjacent data is also accessedApplicable in Principle Look into Android specifics for   this, regarding "guarantee no adjacent data is accessed".
POS50-C.   Declare objects shared between POSIX threads with appropriate storage   durationsApplicable in Principle 
POS51-C.   Avoid deadlock with POSIX threads by locking in predefined orderApplicable in Principle 
POS52-C.   Do not perform operations that can block while holding a POSIX lockApplicable in Principle 
POS53-C.   Do not use more than one mutex for concurrent waiting operations on a   condition variableApplicable in Principle 
POS54-C.   Detect and handle POSIX library errorsApplicable in Principle 
RecommendationsAndroid app development applicable?Comments
WIN00-C.   Be specific when dynamically loading librariesNot applicableAndroid apps are not used in a Microsoft environment
WIN01-C.   Do not forcibly terminate executionNot applicableAndroid apps are not used in a Microsoft environment
WIN02-C.   Restrict privileges when spawning child processesNot applicableAndroid apps are not used in a Microsoft environment
WIN03-C.   Understand HANDLE inheritanceNot applicableAndroid apps are not used in a Microsoft environment
WIN04-C.   Consider encrypting function pointersNot applicableAndroid apps are not used in a Microsoft environment
RulesAndroid app development applicable?Comments
WIN30-C.   Properly pair allocation and deallocation functionsNot applicableAndroid apps are not used in a Microsoft environment

 

 

  • No labels