16f6c0aecf
Inline adoc files when they are included exactly once. Also fix language tags because this inlining gives us better information on what language the code is written in.
117 lines
3.9 KiB
Plaintext
117 lines
3.9 KiB
Plaintext
== Why is this an issue?
|
|
|
|
Outside of the context of an array, explicitly calculating a pointer value will almost never yield the intended result. Even variables declared in the same statement should not be assumed to inhabit sequential memory addresses.
|
|
|
|
|
|
Using an explicitly calculated pointer will have unexpected runtime results as you either read or modify the wrong memory addresses.
|
|
|
|
|
|
Within limits, array indexes are an acceptable form of pointer math _when_ the pointer in question is an array pointer _and_ the array does not hold polymorphic objects/structs.
|
|
|
|
|
|
=== Noncompliant code example
|
|
|
|
[source,cpp]
|
|
----
|
|
void f(char *c) {
|
|
int i = 0;
|
|
int j = 0;
|
|
int *p1 = &i + 1; // Noncompliant: arithmetic not allowed
|
|
int *p2 = &i;
|
|
p2++; // Noncompliant. Presumably intended to point to j. No guarantee that it does.
|
|
|
|
char c2 = c[1]; // Noncompliant; not an array context
|
|
char *c3 = c + 1; // Noncompliant: arithmetic not allowed
|
|
}
|
|
----
|
|
|
|
|
|
=== Exceptions
|
|
|
|
Because it can be convenient to treat an array as a contiguous set of memory addresses, the increment operator (``{plus}{plus}``) is allowed in an array context.
|
|
|
|
|
|
[source,cpp]
|
|
----
|
|
char message[] = "Hello world"; // implicitly null-terminated
|
|
char *p;
|
|
|
|
for (p = message; *p; p++) { // Compliant
|
|
// do something;
|
|
}
|
|
----
|
|
|
|
|
|
== Resources
|
|
|
|
* MISRA C:2004, 17.1
|
|
* MISRA C:2004, 17.2
|
|
* MISRA C:2004, 17.4
|
|
* MISRA {cpp}:2008, 5-0-15
|
|
* MISRA {cpp}:2008, 5-0-16
|
|
* MISRA {cpp}:2008, 5-0-17
|
|
* MISRA C:2012, 18.1
|
|
* MISRA C:2012, 18.2
|
|
* MISRA C:2012, 18.4
|
|
* https://wiki.sei.cmu.edu/confluence/x/1dUxBQ[CERT, ARR37-C.] - Do not add or subtract an integer to a pointer to a non-array object
|
|
* https://wiki.sei.cmu.edu/confluence/x/ytYxBQ[CERT, ARR39-C.] - Do not add or subtract a scaled integer to a pointer
|
|
* https://wiki.sei.cmu.edu/confluence/x/o3w-BQ[CERT, CTR56-CPP.] - Do not use pointer arithmetic on polymorphic objects
|
|
|
|
|
|
|
|
ifdef::env-github,rspecator-view[]
|
|
|
|
'''
|
|
== Implementation Specification
|
|
(visible only on this page)
|
|
|
|
=== Message
|
|
|
|
Do not perform arithmetic on pointers.
|
|
|
|
|
|
'''
|
|
== Comments And Links
|
|
(visible only on this page)
|
|
|
|
=== relates to: S5410
|
|
|
|
=== is related to: S939
|
|
|
|
=== is related to: S942
|
|
|
|
=== on 17 Sep 2014, 10:18:12 Freddy Mallet wrote:
|
|
@Ann, if my feeling is correct there is a misunderstanding somewhere because for me the main goal of those MISRA rules is to prevent any expression on pointers :
|
|
|
|
----
|
|
uint8_t * p1;
|
|
uint8_t * p2;
|
|
|
|
p1++; //non compliant
|
|
p2--; //non compliant
|
|
p1 - p2; //non compliant
|
|
p1 < p2; //non compliant
|
|
----
|
|
|
|
The only exception is when those pointers are used to address an array element.
|
|
|
|
|
|
According to the provided code snippets, I've the feeling that you're trying to cover check something else : prevent accessing to an array element outside of the known limit of the array.
|
|
|
|
=== on 19 Sep 2014, 07:47:55 Ann Campbell wrote:
|
|
\[~freddy.mallet] I had the same initial impression from reading the MISRA rule titles.
|
|
|
|
|
|
The 2004 descriptions are quite curt, but the description and code samples for the 2012 versions of the same rules are quite extensive. To your specific concern, using pointer math to access an array element outside the bounds of the array is the first thing mentioned in MISRA C:2012, 18.1.
|
|
|
|
|
|
I was very tempted to leave out much of the detail, or to try to split it into multiple rules, but in the end decided it was all integral to the same topic.
|
|
|
|
=== on 16 Feb 2015, 20:02:15 Ann Campbell wrote:
|
|
\[~evgeny.mandrikov] http://cwe.mitre.org/data/definitions/131[CWE-131] relates to this rule but has a broader scope (some of which is handled in RSPEC-2613). How would you like to handle? Move all access-beyond-end-of-buffer to a separate rule?
|
|
|
|
=== on 9 Oct 2019, 16:31:19 Amélie Renard wrote:
|
|
I have modified the rule to remove everything related to arrays out of bounds so that it does not overlap with https://jira.sonarsource.com/browse/RSPEC-3519[RSPEC-3519] which deals with buffer overflows in general.
|
|
|
|
endif::env-github,rspecator-view[]
|