MISRA.STDLIB.WRONGNAMEReused name of standard library macro, object or function.
MISRA C 2012 Rule 21.2: A reserved identifier or macro name shall not be declaredC90 [Undefined 5 7, 58, 64, 71], C99 [Undefined 93, 100, 101, 104, 108, 116, 118, 130] Category: Required Analysis: Decidable, Single Translation Unit Applies to: C90, C99 AmplificationSee the Amplification for Rule 21.1 for a description of the relevant identifiers and macro names. RationaleThe implementation is permitted to rely on reserved identifiers behaving as described in The Standard and may treat them specially. If reserved identifiers are reused, the program may exhibit undefined behaviour. ExampleIn the following non-compliant example, the function memcpy is declared explicitly. The compliant method of declaring this function is to include <string.h>. /* * Include <stddef.h> to define size_t */ #include <stddef.h> extern void *memcpy ( void *restrict s1, const void *restrict s2, size_t n ); An implementation is permitted to provide a function-like macro definition for each Standard Library function in addition to the library function itself. This feature is often used by compiler writers to generate efficient inline operations in place of the call to a library function. Using a function-like macro, the call to a library function can be replaced with a call to a reserved function that is detected by the compiler’s code generation phase and replaced with the inline operation. For example, the fragment of <math.h> that declares sqrt might be written using a function-like macro that generates a call to _BUILTIN_sqrt which is replaced with an inline SQRT instruction on processors that support it:
extern double sqrt ( double x ); #define sqrt( x ) ( _BUILTIN_sqrt ( x ) ) The following non-compliant code might interfere with the compiler’s built-in mechanism for handling sqrt and therefore produce undefined behaviour:
#define _BUILTIN_sqrt( x ) ( x ) /* Non-compliant */ #include <math.h> float64_t x = sqrt ( ( float64_t ) 2.0 ); /* sqrt may not behave as * defined in The Standard */ MISRA-C 2004 Rule 20.2 (required): The names of standard library macros, objects and functions shall not be reused.Reused name of standard library macro, object or function. This rule is also covered by MISRA.STDLIB.WRONGNAME.UNDERSCORE, MISRA.UNDEF.WRONGNAME AND MISRA.UNDEF.WRONGNAME.UNDERSCORE. Where new versions of standard library macros, objects or functions are used by the programmer (e.g. enhanced functionality or checks of input values) the modified macro, object or function shall have a new name. This is to avoid any confusion as to whether a standard macro, object or function is being used or whether a modified version of that function is being used. So, for example, if a new version of the sqrt function is written to check that the input is not negative, the new function shall not be named "sqrt" but shall be given a new name. MISRA-C++ 2008 Rule 17-0-3 (required): The names of standard library functions shall not be overridden.This rule is also covered by MISRA.STDLIB.WRONGNAME.UNDERSCORE. RationaleWhere the developer uses new versions of standard library functions (e.g. to enhance functionality or add checks of input values), the modified function shall have a new name. However, it is permissible to overload the name to add new parameter types if the functionality is consistent with those of the original. This ensures that the behaviour associated with the name remains consistent. So, for example, if a new version of the sqrt function is written to check that the input is not negative, the new function shall not be named "sqrt", but shall be given a new name. It is permissible to add a new sqrt function for a type not present in the library. Exampleint32_t printf ( int32_t a, int32_t b ) // Non-compliant { return ( ( a > b ) ? a : b ); } |