== 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[]
