linux-kernel - Re: [PATCH] checkpatch: add --fix option for OPEN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CABJPP5DiUXErqQCuiWz1ALXQ7+2O4tVOMLQJTZHkCz_GqdM2Qg@mail.gmail.com>
Date:   Thu, 19 Nov 2020 02:22:20 +0530
From:   Dwaipayan Ray <dwaipayanray1@...il.com>
To:     Joe Perches <joe@...ches.com>
Cc:     linux-kernel-mentees@...ts.linuxfoundation.org,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Lukas Bulwahn <lukas.bulwahn@...il.com>
Subject: Re: [PATCH] checkpatch: add --fix option for OPEN_BRACE issues

> > > The difference here is that you are dealing with a $stat context and
> > > the existing --fix entries are just for single line fixes.
> > >
> >
> > Hi,
> > Ya I understand that. Though I am dealing with $stat content,
> > I am also directly accessing $rawlines here.
> > So I think that should have the proper patch line format, starting
> > with + or - or so.
> >
> > So in this case if the error is triggered, checking for /^+/ should be done
> > becase it would be wrong to fix the others with /^[- ]/
> >
> > Is there something else that I am not getting here?
>
> $stat does not include lines that are skipped if the lines start with -
>
> Patch context may be:
>
> line    content
>
> 1               func(...
> 2       -            original arguments);
> 3       +            changed);
>
> where $stat does not include the 'original arguments' changed line
>
>         func(...,
>              changed);
>
> but the $rawlines[] entries are consecutive.
>
> Anyway, this needs to be handled very carefully if handled at all.
>
> I think it's easier to avoid handling these cases and let the
> patch submitter fix it manually if appropriate.
>

Thanks. I get your point now. It seems it's much more complex than
I thought it to be. I will avoid working on this one then.

Thanks & Regards,
Dwaipayan.