<![CDATA[MISRA Discussion Forums - 8.21 Standard libraries]]> https://forum.misra.org.uk/ Thu, 05 Nov 2026 15:13:48 +0000 MyBB <![CDATA[21.18 is a safe strncpy function call non-compliant?]]> https://forum.misra.org.uk/showthread.php?tid=1650 Thu, 15 Jun 2023 13:06:38 +0000 dunno]]> https://forum.misra.org.uk/showthread.php?tid=1650

Example code:

void foo() {
    char buf[128];
    strncpy(buf, "hello", 128);
}

The strncpy call does not have any undefined behavior. It will write "hello" in the buffer. Writing 6 bytes in a 128 byte buffer is not undefined behavior.

Does this code then violate rule 21.18? The third argument is larger than the size of the string literal.

Reading the amplification, it seems to me the code in non-compliant.

Reading the rationale, the point of this rule is to avoid buffer overflows. Since there is no buffer overflow does it mean the code is compliant?]]>

Example code:

void foo() {
    char buf[128];
    strncpy(buf, "hello", 128);
}

The strncpy call does not have any undefined behavior. It will write "hello" in the buffer. Writing 6 bytes in a 128 byte buffer is not undefined behavior.

Does this code then violate rule 21.18? The third argument is larger than the size of the string literal.

Reading the amplification, it seems to me the code in non-compliant.

Reading the rationale, the point of this rule is to avoid buffer overflows. Since there is no buffer overflow does it mean the code is compliant?]]> <![CDATA[Rule 21.8, assert, and abort]]> https://forum.misra.org.uk/showthread.php?tid=1550 Mon, 02 Nov 2020 22:21:24 +0000 michael.metivier]]> https://forum.misra.org.uk/showthread.php?tid=1550 <![CDATA[Shall Rule 21.1 apply to the both paths of conditional preprocessing]]> https://forum.misra.org.uk/showthread.php?tid=1532 Wed, 04 Mar 2020 02:28:02 +0000 chenzhuowansui]]> https://forum.misra.org.uk/showthread.php?tid=1532 Rule 21.1 doesn't mention anything about preprocessing, so given the following code
Code:
#define ABC 345

#ifdef ABC
#define _XYZ 0xFFFFFFFF    //defect1
#else
#define _XYZ 0xF0000000  //defect2
#endif

shall we report both the above defects or only the one(defec1) in the true path?

thanks]]> Rule 21.1 doesn't mention anything about preprocessing, so given the following code
Code:
#define ABC 345

#ifdef ABC
#define _XYZ 0xFFFFFFFF    //defect1
#else
#define _XYZ 0xF0000000  //defect2
#endif

shall we report both the above defects or only the one(defec1) in the true path?

thanks]]> <![CDATA[Rules 21.1 and 21.2. Possible contradiction with rule 11.9 and directive 4.6.]]> https://forum.misra.org.uk/showthread.php?tid=1474 Fri, 22 Feb 2019 19:44:10 +0000 l.inc]]> https://forum.misra.org.uk/showthread.php?tid=1474
Problems arise when trying to adhere to the rule 11.9 by defining the macro "NULL" and to the directive 4.6 by defining the exact-width integer types. These rules prescribe the use of standard names while the rules 21.1 and 21.2 prohibit such definitions. The project employs static assertions to guarantee that all the standard properties of the exact-width integer types and other integer types (like "size_t" and "ptrdiff_t") hold true for whatever (32-bit or 64-bit) target the project is compiled. The project is C99-specific, and I assume the MISRA C Working Group would rightfully point out that the directive 4.6 recommends inclusion of "stdint.h" in this case and therefore does not strictly contradict the rule 21.2 due to the standard headers being out of the MISRA C compliance scope. In any case the rationale of the rule 21.2 does not seem to apply here, as the typedef-names have no linkage and are therefore not reserved as per "C99. 7.1.3 Reserved identifiers" as long as no associated header is included.

My questions are:
1) How can the contradiction between the rules 11.9 and 21.1 be resolved with respect to the macro "NULL" in the context of the given project?
2) How can the contradiction between the directive 4.6 and the rule 21.2 be resolved with respect to the exact-width integer types in the context of the given project?
3) Rule 21.1 acknowledges that defining identifiers being subject to the question 2 "is well-defined provided that the header is not included", but still prohibits such definitions to avoid confusion. Does this prohibition also apply for the rule 21.2? What exactly causes confusion provided all the properties guaranteed by the standard are also ensured for the definitions made outside of the standard headers?

Kind regards]]>
Problems arise when trying to adhere to the rule 11.9 by defining the macro "NULL" and to the directive 4.6 by defining the exact-width integer types. These rules prescribe the use of standard names while the rules 21.1 and 21.2 prohibit such definitions. The project employs static assertions to guarantee that all the standard properties of the exact-width integer types and other integer types (like "size_t" and "ptrdiff_t") hold true for whatever (32-bit or 64-bit) target the project is compiled. The project is C99-specific, and I assume the MISRA C Working Group would rightfully point out that the directive 4.6 recommends inclusion of "stdint.h" in this case and therefore does not strictly contradict the rule 21.2 due to the standard headers being out of the MISRA C compliance scope. In any case the rationale of the rule 21.2 does not seem to apply here, as the typedef-names have no linkage and are therefore not reserved as per "C99. 7.1.3 Reserved identifiers" as long as no associated header is included.

My questions are:
1) How can the contradiction between the rules 11.9 and 21.1 be resolved with respect to the macro "NULL" in the context of the given project?
2) How can the contradiction between the directive 4.6 and the rule 21.2 be resolved with respect to the exact-width integer types in the context of the given project?
3) Rule 21.1 acknowledges that defining identifiers being subject to the question 2 "is well-defined provided that the header is not included", but still prohibits such definitions to avoid confusion. Does this prohibition also apply for the rule 21.2? What exactly causes confusion provided all the properties guaranteed by the standard are also ensured for the definitions made outside of the standard headers?

Kind regards]]> <![CDATA[Doubts about Rule 21.3 and 21.8]]> https://forum.misra.org.uk/showthread.php?tid=1473 Thu, 21 Feb 2019 02:32:30 +0000 chenzhuowansui]]> https://forum.misra.org.uk/showthread.php?tid=1473
We have some doubts about Rule 21.3 and Rule 21.8, please help clarify

Rule 21.3 The memory allocation and deallocation functions of shall not be used
Rule 21.8 The library functions abort, exit, getenv and system of shall not be used

From the titles and Rationale of these two rules, they are talking about only functions with the forbidden identifiers, but in the Amplification of these two rules, all these identifiers and macros are forbidden including using these identifiers to define variables or fields of structs. So my question is that can we use these identifiers in the following cases:

Code:
int free = 0; //Violate Rule 21.3?
struct s {
    int free;   //Violate Rule 21.3?
    int malloc; //Violate Rule 21.3?
    int exit; //Violate Rule 21.8?
    };

Please help clarify, thanks a lot!]]>
We have some doubts about Rule 21.3 and Rule 21.8, please help clarify

Rule 21.3 The memory allocation and deallocation functions of shall not be used
Rule 21.8 The library functions abort, exit, getenv and system of shall not be used

From the titles and Rationale of these two rules, they are talking about only functions with the forbidden identifiers, but in the Amplification of these two rules, all these identifiers and macros are forbidden including using these identifiers to define variables or fields of structs. So my question is that can we use these identifiers in the following cases:

Code:
int free = 0; //Violate Rule 21.3?
struct s {
    int free;   //Violate Rule 21.3?
    int malloc; //Violate Rule 21.3?
    int exit; //Violate Rule 21.8?
    };

Please help clarify, thanks a lot!]]> <![CDATA[How do explicit casts of arguments affect 21.15 (amendment 1)?]]> https://forum.misra.org.uk/showthread.php?tid=1415 Mon, 09 Apr 2018 19:45:39 +0000 abgs]]> https://forum.misra.org.uk/showthread.php?tid=1415
Code:
void f(signed char* a, int* b, size_t n) {
    memcmp(a, a, n); // ok - pointers to same type
    memcmp(b, b, n); // ok - pointers to same type
    memcmp((int*)b, (int*)b, n); // ok - same type and cast has no effect
    memcmp((int*)a, (int*)a, n); // ok? - cast to different pointer type, arguments match before and after but with different matching types
    memcmp(a, b, n); // violation - pointers to different types
    memcmp((int*)a, b, n); // violation? - types only match due to pointer cast
    memcmp((float*)a, (float*)b, n); // violation? - different pointer types cast to third common pointer type
    memcmp((short*)a, a, n); // violation? - original pointer types match before cast
}
]]>
Code:
void f(signed char* a, int* b, size_t n) {
    memcmp(a, a, n); // ok - pointers to same type
    memcmp(b, b, n); // ok - pointers to same type
    memcmp((int*)b, (int*)b, n); // ok - same type and cast has no effect
    memcmp((int*)a, (int*)a, n); // ok? - cast to different pointer type, arguments match before and after but with different matching types
    memcmp(a, b, n); // violation - pointers to different types
    memcmp((int*)a, b, n); // violation? - types only match due to pointer cast
    memcmp((float*)a, (float*)b, n); // violation? - different pointer types cast to third common pointer type
    memcmp((short*)a, a, n); // violation? - original pointer types match before cast
}
]]> <![CDATA[Use reserved identifier as input parameter of function]]> https://forum.misra.org.uk/showthread.php?tid=1341 Tue, 25 Apr 2017 06:25:49 +0000 lai56]]> https://forum.misra.org.uk/showthread.php?tid=1341
It is defined in the Rule 21.2 that reserved identifier from standard library should not be used.

I have following example for a function definition.
void func_a (uint8 time)

time is reserved identifier from time.h, but it is used as input paramter for the function syntax. does it violate the rule 21.2?

Thanks
Lai]]>
It is defined in the Rule 21.2 that reserved identifier from standard library should not be used.

I have following example for a function definition.
void func_a (uint8 time)

time is reserved identifier from time.h, but it is used as input paramter for the function syntax. does it violate the rule 21.2?

Thanks
Lai]]> <![CDATA[Rule 21.18 (Amendment) - Use of '0']]> https://forum.misra.org.uk/showthread.php?tid=1316 Fri, 24 Feb 2017 15:21:05 +0000 RichardC]]> https://forum.misra.org.uk/showthread.php?tid=1316
The Amplification specifies that the value be "positive". However, that can be interpreted as "greater than" zero. However, according the to C standard (C99 7.21.1/2) it is well defined to call these functions with a value of 0:

Quote:Where an argument declared as size_t n specifies the length of the array for a function, n can have the value zero on a call to that function. Unless explicitly stated otherwise in the description of a particular function in this subclause, pointer arguments on such a call shall still have valid values, as described in 7.1.4. On such a call, a function that locates a character finds no occurrence, a function that compares two character sequences returns zero, and a function that copies characters copies zero characters.

1) Given that 0 has well-defined meaning, does 'positive' imply "greater than zero" or "greater than or equal to zero"?

2) If positive refers to "greater than zero", is there an example or rationale for excluding this well-defined behavior?


Many Thanks.]]>
The Amplification specifies that the value be "positive". However, that can be interpreted as "greater than" zero. However, according the to C standard (C99 7.21.1/2) it is well defined to call these functions with a value of 0:

Quote:Where an argument declared as size_t n specifies the length of the array for a function, n can have the value zero on a call to that function. Unless explicitly stated otherwise in the description of a particular function in this subclause, pointer arguments on such a call shall still have valid values, as described in 7.1.4. On such a call, a function that locates a character finds no occurrence, a function that compares two character sequences returns zero, and a function that copies characters copies zero characters.

1) Given that 0 has well-defined meaning, does 'positive' imply "greater than zero" or "greater than or equal to zero"?

2) If positive refers to "greater than zero", is there an example or rationale for excluding this well-defined behavior?


Many Thanks.]]> <![CDATA[A question for Rule21.8]]> https://forum.misra.org.uk/showthread.php?tid=1076 Mon, 14 Jul 2014 06:28:49 +0000 tsukukazu]]> https://forum.misra.org.uk/showthread.php?tid=1076
I have a question about rule 21.8.

_Exit Function that were added in C99 also has implementation-defined behavior.

Is this not included?

Best regards,
Kazuhiro Tsukushiro]]>
I have a question about rule 21.8.

_Exit Function that were added in C99 also has implementation-defined behavior.

Is this not included?

Best regards,
Kazuhiro Tsukushiro]]> <![CDATA["See Also" in Rule 21.1]]> https://forum.misra.org.uk/showthread.php?tid=1060 Thu, 05 Jun 2014 06:57:11 +0000 tsukukazu]]> https://forum.misra.org.uk/showthread.php?tid=1060 But "See also" of this rule does not contain "Rule 20.5 # undef should not be used".
I think Rule 20.5 should be included in "See also".

Is it correct?

Best Regards.]]> But "See also" of this rule does not contain "Rule 20.5 # undef should not be used".
I think Rule 20.5 should be included in "See also".

Is it correct?

Best Regards.]]> <![CDATA[Phrase in Rule 21.7 and Rule 21.8]]> https://forum.misra.org.uk/showthread.php?tid=1058 Thu, 22 May 2014 05:52:43 +0000 ogawa.kiyoshi]]> https://forum.misra.org.uk/showthread.php?tid=1058 Rule 21.8 The library functions abort, exit getenv and system of shall not be used.

If the purpose of the rules are same, wording should be same in the standard document.

"The Standard Library" or "The library" , also.]]> Rule 21.8 The library functions abort, exit getenv and system of shall not be used.

If the purpose of the rules are same, wording should be same in the standard document.

"The Standard Library" or "The library" , also.]]> <![CDATA[Words in Rule 21.1 and 21.2]]> https://forum.misra.org.uk/showthread.php?tid=1057 Thu, 22 May 2014 05:21:05 +0000 ogawa.kiyoshi]]> https://forum.misra.org.uk/showthread.php?tid=1057 Rule 21.2 A reserved identifier or macro name shall not be declared

" reserved macro name " or "macro name".

Do you choose the usage of either?

I expect a normalization of the words in the standard document.]]> Rule 21.2 A reserved identifier or macro name shall not be declared

" reserved macro name " or "macro name".

Do you choose the usage of either?

I expect a normalization of the words in the standard document.]]> <![CDATA[Alternative to time.h]]> https://forum.misra.org.uk/showthread.php?tid=1052 Wed, 23 Apr 2014 16:17:40 +0000 gwillits]]> https://forum.misra.org.uk/showthread.php?tid=1052
I'm relatively new to C, new to MISRA guidelines, and trying to wrap my head around how to substitute for the time.h library. I've internet-searched my brains out looking for some clue as to what people do for time functions. Do they completely re-implement their own code in order to avoid the "unspecified, undefined and implementation-defined behaviours" of the standard library?

Given the expansion of Rationale of the 2012 over 2004 documentation, it surprised me there's no suggestions of what best practice alternatives are to the things which "shall not be used".

Anyway, I'd appreciate anyone's input as to what MISRA conforming code does for time functionality.

Many thanks,

-- gw]]>
I'm relatively new to C, new to MISRA guidelines, and trying to wrap my head around how to substitute for the time.h library. I've internet-searched my brains out looking for some clue as to what people do for time functions. Do they completely re-implement their own code in order to avoid the "unspecified, undefined and implementation-defined behaviours" of the standard library?

Given the expansion of Rationale of the 2012 over 2004 documentation, it surprised me there's no suggestions of what best practice alternatives are to the things which "shall not be used".

Anyway, I'd appreciate anyone's input as to what MISRA conforming code does for time functionality.

Many thanks,

-- gw]]> <![CDATA[Definition of "declare" for Rule 21.2]]> https://forum.misra.org.uk/showthread.php?tid=1051 Thu, 17 Apr 2014 04:22:33 +0000 satoshi]]> https://forum.misra.org.uk/showthread.php?tid=1051
C90/C99 use the "declare" for function declarations and variable declarations.
And, macros are used the "define".

Quote:p.167
#define __BUILTIN_sqrt(x) (x) /* Non-compliant */

"example" is a rule violation for the macro definition.
To error the macro definitions could not be a role of rule 21.1?


-----
Best regards,
Satoshi Kawajiri]]>
C90/C99 use the "declare" for function declarations and variable declarations.
And, macros are used the "define".

Quote:p.167
#define __BUILTIN_sqrt(x) (x) /* Non-compliant */

"example" is a rule violation for the macro definition.
To error the macro definitions could not be a role of rule 21.1?


-----
Best regards,
Satoshi Kawajiri]]> <![CDATA[sample comment for Rule 21.1]]> https://forum.misra.org.uk/showthread.php?tid=1050 Thu, 17 Apr 2014 03:06:24 +0000 satoshi]]> https://forum.misra.org.uk/showthread.php?tid=1050
Quote:#define defined /* Non-compliant - reserved identifier */

And, It is written as follows in the "amplification":
  • Identifiers or macro names beginning with underscore.
  • Identifiers in file scope described in Section 7

I was thinking "the identifiers which is limited by this rule is
the identifiers(ex. memcpy, errno, ...) that defined in the library section of the C90/C99."

If the rationale of the comment is the following statement, can I be considered that the normal reserved identifiers(ex. int, typedef, ...) are OK?
Of course, although not preferred, int or etc. are excluded as rule 21.1?

Quote:This rule prohibits the use of #define or #undef on th identifier defined as ...

-----
Best regards,
Satoshi Kawajiri]]>
Quote:#define defined /* Non-compliant - reserved identifier */

And, It is written as follows in the "amplification":
  • Identifiers or macro names beginning with underscore.
  • Identifiers in file scope described in Section 7

I was thinking "the identifiers which is limited by this rule is
the identifiers(ex. memcpy, errno, ...) that defined in the library section of the C90/C99."

If the rationale of the comment is the following statement, can I be considered that the normal reserved identifiers(ex. int, typedef, ...) are OK?
Of course, although not preferred, int or etc. are excluded as rule 21.1?

Quote:This rule prohibits the use of #define or #undef on th identifier defined as ...

-----
Best regards,
Satoshi Kawajiri]]>