Clarification of Rule 17.4

[Lundin]

I don't see the purpose of this TC or the part of the rule not allowing pointers to use the index operator.

Because there is absolutely no difference between pointer function parameters and array function parameters in ISO C (as long as the array size isn't static and typed out explicitly). It becomes quite ridiculous if you put it this way:

Code:

void my_fn (uint8_t* p1, uint8_t p2[])
{
  p1[5] = 0;     /* this segmentation fault is not compliant */
  p2[5] = 0;     /* this segmentation fault is compliant */
}

int main()
{
  uint8_t array [2];

  my_fn(array, array);
}

The chances of the index for p1 to be calculated incorrectly are the very same as the chances for the p2 index. The array [] syntax doesn't help compilers nor static analysis tools to spot out-of-bounds bugs, unless the size of the array pointer is typed out explicitly. Neither does C support boundary checks of arrays.

I also don't understand why performing for example increment operations on integer indices is considered less error-prone than pointer increments. It is just as easy for the programmer to calculate integer index values incorrectly as it is to calculate pointer calues. I don't see how pointers are less \"clean\" either.

I would even call integer indices less safe, because of the following situation:

Code:

short index = 32767;
  short* ptr = array + 32767;

  index++;
  ptr++;

  array[index] = 0; /* possible bug depending on int \"signedness\" */
  *ptr = 0;         /* will work fine on all systems*/

No matter how you put it, this is all in the hands of the programmer, who may produce as many out-of-bounds bugs as they wish regardless of this rule.

If anything should be banned, it is using the syntax

*(array + n) /* compliant if array type? */

rather than

array[n]

because I think most will agree that the second version is easier to read and understand.