== Why is this an issue?

The ``++sizeof++`` operator returns the size, in bytes, of its operand, which can be an expression or a type.


Function parameters with array types automatically decay to pointers, so it is hazardous to call the ``++sizeof++`` operator on such variables.


Moreover, calling the ``++sizeof++`` operator on a variable with pointer type is typically a mistake. Usually the intent was to get the size of the pointed-to value instead.


=== Noncompliant code example

[source,text]
----
void clear1(int array[]) {
  for (size_t i = 0; i < sizeof(array) / sizeof(*array); i+=1) { // Noncompliant, type of array decays to int *, so sizeof(array) evaluates to sizeof(int *)
     array[i] = 0;
   }
}

void clear2(short *array, int count) {
  memset(array, sizeof(array) * count); // Noncompliant, sizeof(array) evaluates to the size of a pointer to short and not of a short
}
----


== Resources

* CWE - https://cwe.mitre.org/data/definitions/467[CWE-467 - Use of sizeof() on a Pointer Type]

ifdef::env-github,rspecator-view[]

'''
== Comments And Links
(visible only on this page)

=== on 10 Feb 2015, 13:48:04 Samuel Mercier wrote:
\[~evgeny.mandrikov] I rewrote the rule to prevent usage of ``++sizeof++`` on a variable with pointer type

\[~ann.campbell.2] Could you verify?

=== on 10 Feb 2015, 13:55:58 Ann Campbell wrote:
I've made some updates [~samuel.mercier] that you probably want to check. Since this is not a MISRA rule, then we should use the standard format for the title: "X should [not] y", rather than using "shall".


Also, I'm not wild about the message. I'd either go with "Remove this use of..." or '"x" is a pointer'.

=== on 13 Feb 2015, 08:44:14 Samuel Mercier wrote:
\[~ann.campbell.2] ok for title. For the message, in past, we already had this discussion :) '"x" is a pointer' doesn't say anything about neither the problem nor the resolution, so it should be avoided. I also don't really like the "remove" form because there are really two cases covered by this rule:

1) sizeof is used on a function parameter with type array. in that case sizeof should effectively be removed and an additional size argument must be provided

2) sizeof is probably badly used on a pointer, so there is probably a missing * : sizeof(p) -> sizeof(*p)

so among the three I would stick with the current one.

=== on 13 Feb 2015, 12:20:36 Ann Campbell wrote:
Okay [~samuel.mercier]


endif::env-github,rspecator-view[]
