On 25.08.2025 19:33, Dmytro Prokopchuk1 wrote: > > > 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. > > 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?
Fine with me, yes. Jan
