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: <CABJPP5AvdWDJP1mkpdk_y-OVQnJb7utC3qCqOn=vP93DC7QwGg@mail.gmail.com>
Date:   Thu, 1 Oct 2020 21:06:22 +0530
From:   Dwaipayan Ray <dwaipayanray1@...il.com>
To:     Joe Perches <joe@...ches.com>
Cc:     linux-kernel@...r.kernel.org,
        linux-kernel-mentees@...ts.linuxfoundation.org,
        Lukas Bulwahn <lukas.bulwahn@...il.com>
Subject: Re: [PATCH RFC] checkpatch: fix multi-statement macro checks

> > All I'm trying to point out to you is that $Constant\s*$Constant
> > isn't a proper test as the first $Constant will pull the test
> > entire sequence of digits and the second $Constant will not be
> > met.
> >
> > It may take some conversion of the collapsing of the dstat
> > block to work appropriately
> >
> >
> >                       # Flatten any parentheses and braces
> >                       while ($dstat =~ s/\([^\(\)]*\)/1/ ||
> >                              $dstat =~ s/\{[^\{\}]*\}/1/ ||
> >                              $dstat =~ s/.\[[^\[\]]*\]/1/)
> >                       {
> >                       }
> >
> > Maybe the /1/ should be / 1 / but I didn't look to see what
> > happens to the exclusion tests below that.
>
> I think your patch would work well enough if the /1/ bits
> here were simply changed to /1u/.
>
> 1 is a $Constant as it's just a number.
> 11 though is also a $Constant.
> 1u is also a $Constant but it stops the acquisition of
> digits that 11 would not and the sequence of
> "while1u1u" should match your newly introduced test
> of $Constant\s*$Constant as "while11" would not match.
>
>

Hi,
That's an amazing idea! I tried it and this time it seems to
detect it properly. Also this fixes the similar case in
for(...) {...}.

It should not have any side effects also for other checks.
Pretty amazing.

I will rewrite the patch with your suggestion and send it
back.

Thanks,
Dwaipayan.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ