Re: [PATCH] misra: add deviation of Rule 17.7

[Dmytro Prokopchuk1 <dmytro_prokopchuk1@xxxxxxxx>]

On 8/25/25 17:12, Jan Beulich wrote:
> On 25.08.2025 15:27, Dmytro Prokopchuk1 wrote:
>>
>>
>> On 8/25/25 14:07, Jan Beulich wrote:
>>> On 25.08.2025 12:58, Dmytro Prokopchuk1 wrote:
>>>> On 8/25/25 13:30, Jan Beulich wrote:
>>>>> On 25.08.2025 11:05, Dmytro Prokopchuk1 wrote:
>>>>>> MISRA C Rule 17.7 states: "The value returned by a function having
>>>>>> non-void return type shall be used."
>>>>>>
>>>>>> Deviate functions like 'memcpy()', 'memset()', 'memmove()', 'snprintf()',
>>>>>> 'strlcpy()', 'strlcat()', as they return a value purely for convenience,
>>>>>> their primary functionality (e.g., memory or string operations) remains
>>>>>> unaffected, and their return values are generally non-critical and seldom
>>>>>> relied upon. Update 'deviations.rst' file accordingly.
>>>>>
>>>>> How come snprintf() is among this set? Its return value isn't quite just
>>>>> for convenience, imo.
>>>>
>>>> Yes, snprintf()'s return value isn't just for convenience. The deviation
>>>> justification is primarily based on the fact that its return value is
>>>> rarely used in the Xen source base. Most callers of snprintf() don't
>>>> care about return value. So, snprintf() is in this list.
>>>>
>>>> Maybe separate wording is required for the snprintf() ?
>>>
>>> Minimally. Personally I don't think it should be deviated globally.
>>
>> There are approximately 230 instances of snprintf() being used without
>> checking its return value (across ARM and x86) in around 20 different
>> source files. Deviation each of them could be complicated.
> 
> My grep yields somewhere between 50 and 60 hits in xen/, among them about 15
> in xen/tools/kconfig/, which I expect we can ignore. I also didn't mean to
> suggest to deviate them all individually. Some may actually want to use the
> return value, and I wouldn't be surprised if this ended up fixing a bug or
> two.
> 
> Jan

For memory-related functions (memcpy, memset, memmove), ignoring the 
return value is almost always safe, so I propose to leave these 
functions in the patch, remove snprintf, strlcpy, strlcat so far, and
precisely check usage of the last functions.

Is it OK?