On Fri, 31 Oct 2025, Naman Jain wrote:
>
>
> On 10/31/2025 2:03 PM, Markus Elfring wrote:
> > From: Markus Elfring <[email protected]>
> > Date: Fri, 31 Oct 2025 09:24:31 +0100
> >
> > A pointer was assigned to a variable. The same pointer was used for
> > the destination parameter of a memcpy() call.
> > This function is documented in the way that the same value is returned.
> > Thus convert two separate statements into a direct variable assignment for
> > the return value from a memory copy action.
> >
> > The source code was transformed by using the Coccinelle software.
> >
> > Signed-off-by: Markus Elfring <[email protected]>
> > ---
> > arch/x86/hyperv/hv_crash.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/hyperv/hv_crash.c b/arch/x86/hyperv/hv_crash.c
> > index c0e22921ace1..745d02066308 100644
> > --- a/arch/x86/hyperv/hv_crash.c
> > +++ b/arch/x86/hyperv/hv_crash.c
> > @@ -464,9 +464,7 @@ static int hv_crash_setup_trampdata(u64 trampoline_va)
> > return -1;
> > }
> > - dest = (void *)trampoline_va;
> > - memcpy(dest, &hv_crash_asm32, size);
> > -
> > + dest = memcpy((void *)trampoline_va, &hv_crash_asm32, size);
> > dest += size;
> > dest = (void *)round_up((ulong)dest, 16);
> > tramp = (struct hv_crash_tramp_data *)dest;
>
>
> I tried running spatch Coccinelle checks on this file, but could not get it to
> flag this improvement. Do you mind sharing more details on the issue
> reproduction please.
>
> I am OK with this change, though it may cost code readability a little bit.
> But if this is a result of some known standard rule, added as part of these
> Coccinelle rules, we should be good.
Multiple people have suggested that due to the loos of readability the
change is not a good idea.
It's not done by a standard rule.
julia
