Re: [XEN PATCH 3/5] xen/sort: address violations of MISRA C:2012 Rule 8.2

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 20 Nov 2023, Jan Beulich wrote:
> On 20.11.2023 14:13, Federico Serafini wrote:
> > On 20/11/23 10:02, Jan Beulich wrote:
> >> On 17.11.2023 09:40, Federico Serafini wrote:
> >>> --- a/xen/include/xen/sort.h
> >>> +++ b/xen/include/xen/sort.h
> >>> @@ -23,8 +23,8 @@
> >>>   extern gnu_inline
> >>>   #endif
> >>>   void sort(void *base, size_t num, size_t size,
> >>> -          int (*cmp)(const void *, const void *),
> >>> -          void (*swap)(void *, void *, size_t))
> >>> +          int (*cmp)(const void *key, const void *elem),
> >>
> >> Why "key" and "elem" here, but ...
> >>
> >>> +          void (*swap)(void *a, void *b, size_t size))
> >>
> >> ... "a" and "b" here? The first example of users of sort() that I'm
> >> looking at right now (x86/extable.c) is consistent in its naming.
> >>
> > 
> > On the Arm side there are {cmp,swap}_memory_node() and
> > {cmp,swap}_mmio_handler(): "key"/"elem" are used for the comparison
> > and "_a"/"_b" for the swap.
> 
> So - re-raising a question Stefano did raise - is Misra concerned about
> such discrepancies? If yes, _all_ instances need harmonizing. If not, I
> see no reason to go with misleading names here.

Federico confirmed that the answer is "no".

I think we can use "key" and "elem" in this patch as they are more
informative than "a" and "b"