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
