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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 17 Aug 2020 03:37:00 -0000
From:   Michael Witten <>
To:     Joe Perches <>
Cc:     Masahiro Yamada <>,
        Michal Marek <>,
        Cong Wang <>,
        Johannes Weiner <>,
        Sam Ravnborg <>,,
Subject: Re: [PATCH] Makefile: Yes. Finally remove '-Wdeclaration-after-statement'

Joe Perches (Sun, 16 Aug 2020 10:56:53 -0700):

> I rather prefer block declarations instead of
> sprinkling declarations around with code.

Hey, we all have our guilty pleasures.

Fortunately, even with this patch, you'd still be able to indulge
in your preferred style, or even enforce it among contributors to
the code that you maintain.

However, the following statement should hold:

  If merged code is correct (portable, safe, etc.),
  then the kernel must build without any warning
  about that merged code.

Sometimes, code is clearest (or indeed safest) when it is written
with a variable definition that occurs at a point well within the
body of statements. Authors need to have the option to write such
code; otherwise, style ceases to be means of clarity, and instead
becomes a laborious end unto itself.

Matters of  style should  probably not be  enforced by  the build
infrastructure; style is a matter for the maintainer to enforce:

  * Perhaps there could be a  new build-time switch. By default, 
    the warning can be off for  a normal build; a maintainer can 
    flip the  switch to  turn it on  locally, and  thereby check 
    whether a patch declares  variables unnecessarily hither and 
    thither, as determined by the maintainer's taste.            

  * Perhaps  `scripts/' could  be taught  about this
    issue.  Though probably  easier  said than  done, the  script
    could parse every modified block, and warn about declarations
    after  statements (but  maybe  ignore  the declarations  that
    introduce const variables).

  * Perhaps there is already linting infrastructure that could be
    put to such use.

This way, good code can compile cleanly, and style can just be an
ongoing topic of discussion among contributors.

Michael Witten

Powered by blists - more mailing lists