Rule 21.18 (Amendment) - Use of '0'

[RichardC]

The rationale provided for this rule is to avoid reading or writing passed the bounds of an object argument, resulting in "undefined behavior".

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:

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.

[misra-c]

The term "Positive" should be understood as "greater than zero".

It is accepted that using value of "0" is well-defined, but it is likely to be indicative of a programmer error - e.g. a security vulnerability. We will extend the rationale in a future TC.

[RichardC]

Thank you for the feedback.

I agree with the sentiment that using 0 may be "indicative of a programmer error", however, this is not guaranteed to be the case unlike undefined behavior due to buffer overflow. There may be rare cases where allowing 0 provides for a cleaner solution however, as the rule is Mandatory, the code will need to be modified for it to be made compliant.

For a future version I suggest splitting 21.18 into a 'Mandatory' for the truly dangerous case and add an 'Advisory' guideline to cover the "likely programmer error" of using 0.