Putting declarations before statement is relict of single pass compiler
era. It was necessary to allocate stack slots before generating code.

Recently added static_assert() is a declaration. -Wdeclaration-after-statement
prevents its placement anywhere in the code for no reason.

Placing variable declarations in the beginning of the block increases
variable "LOC lifetime" so to speak and chances that it will be misused.
This is very low probability bug but still. Declaring variables right
before first use will make "LOC lifetime" smaller.

	{
		int x;
		[x is misused due to a typo]
		f(x);	// first correct use
	}

vs

	{
		[can't misuse undeclared variable]
		int x;
		f(x);	// first correct use
	}

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---

 Makefile                          |    3 ---
 arch/arm64/kernel/vdso32/Makefile |    1 -
 tools/power/acpi/Makefile.config  |    1 -
 tools/power/cpupower/Makefile     |    1 -
 tools/scripts/Makefile.include    |    1 -
 5 files changed, 7 deletions(-)

--- a/Makefile
+++ b/Makefile
@@ -933,9 +933,6 @@ endif
 # arch Makefile may override CC so keep this after arch Makefile is included
 NOSTDINC_FLAGS += -nostdinc
 
-# warn about C99 declaration after statement
-KBUILD_CFLAGS += -Wdeclaration-after-statement
-
 # Variable Length Arrays (VLAs) should not be used anywhere in the kernel
 KBUILD_CFLAGS += -Wvla
 
--- a/arch/arm64/kernel/vdso32/Makefile
+++ b/arch/arm64/kernel/vdso32/Makefile
@@ -71,7 +71,6 @@ VDSO_CFLAGS += -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
                -std=gnu89
 VDSO_CFLAGS  += -O2
 # Some useful compiler-dependent flags from top-level Makefile
-VDSO_CFLAGS += $(call cc32-option,-Wdeclaration-after-statement,)
 VDSO_CFLAGS += $(call cc32-option,-Wno-pointer-sign)
 VDSO_CFLAGS += -fno-strict-overflow
 VDSO_CFLAGS += $(call cc32-option,-Werror=strict-prototypes)
--- a/tools/power/acpi/Makefile.config
+++ b/tools/power/acpi/Makefile.config
@@ -63,7 +63,6 @@ OPTIMIZATION := $(call cc-supports,-Os,-O2)
 
 WARNINGS := -Wall
 WARNINGS += $(call cc-supports,-Wstrict-prototypes)
-WARNINGS += $(call cc-supports,-Wdeclaration-after-statement)
 
 KERNEL_INCLUDE := $(OUTPUT)include
 ACPICA_INCLUDE := $(srctree)/../../../drivers/acpi/acpica
--- a/tools/power/cpupower/Makefile
+++ b/tools/power/cpupower/Makefile
@@ -118,7 +118,6 @@ OPTIMIZATION := $(call cc-supports,-Os,-O2)
 
 WARNINGS := -Wall -Wchar-subscripts -Wpointer-arith -Wsign-compare
 WARNINGS += $(call cc-supports,-Wno-pointer-sign)
-WARNINGS += $(call cc-supports,-Wdeclaration-after-statement)
 WARNINGS += -Wshadow
 
 override CFLAGS += -DVERSION=\"$(VERSION)\" -DPACKAGE=\"$(PACKAGE)\" \
--- a/tools/scripts/Makefile.include
+++ b/tools/scripts/Makefile.include
@@ -21,7 +21,6 @@ endif
 # Include saner warnings here, which can catch bugs:
 #
 EXTRA_WARNINGS := -Wbad-function-cast
-EXTRA_WARNINGS += -Wdeclaration-after-statement
 EXTRA_WARNINGS += -Wformat-security
 EXTRA_WARNINGS += -Wformat-y2k
 EXTRA_WARNINGS += -Winit-self

On Fri, 25 Feb 2022 11:15:58 +0300 Alexey Dobriyan <adobriyan@gmail.com> wrote:

> Putting declarations before statement is relict of single pass compiler
> era. It was necessary to allocate stack slots before generating code.
> 
> Recently added static_assert() is a declaration. -Wdeclaration-after-statement
> prevents its placement anywhere in the code for no reason.
> 
> Placing variable declarations in the beginning of the block increases
> variable "LOC lifetime" so to speak and chances that it will be misused.
> This is very low probability bug but still. Declaring variables right
> before first use will make "LOC lifetime" smaller.
> 
> 	{
> 		int x;
> 		[x is misused due to a typo]
> 		f(x);	// first correct use
> 	}
> 
> vs
> 
> 	{
> 		[can't misuse undeclared variable]
> 		int x;
> 		f(x);	// first correct use
> 	}
> 

Oh man.  I so wish you'd cc'ed Linus on this one so we could admire his
reaction.

From: Alexey Dobriyan
> Sent: 25 February 2022 08:16
> 
> Putting declarations before statement is relict of single pass compiler
> era. It was necessary to allocate stack slots before generating code.
> 
> Recently added static_assert() is a declaration. -Wdeclaration-after-statement
> prevents its placement anywhere in the code for no reason.

That could enclose its declaration inside a block.
But then it wouldn't be usable at global scope (is it anyway?)

> Placing variable declarations in the beginning of the block increases
> variable "LOC lifetime" so to speak and chances that it will be misused.
> This is very low probability bug but still. Declaring variables right
> before first use will make "LOC lifetime" smaller.

NAK it makes it very hard for a human (some of us are) to find
the declaration.

Indeed putting them anywhere other that the top of a function
or the top of a very short code block makes them hard to find.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

On Fri, Feb 25, 2022 at 10:01:23AM +0000, David Laight wrote:
> From: Alexey Dobriyan
> > Sent: 25 February 2022 08:16
> > 
> > Putting declarations before statement is relict of single pass compiler
> > era. It was necessary to allocate stack slots before generating code.
> > 
> > Recently added static_assert() is a declaration. -Wdeclaration-after-statement
> > prevents its placement anywhere in the code for no reason.
> 
> That could enclose its declaration inside a block.

It could but why put useless characters on the screen?

> But then it wouldn't be usable at global scope (is it anyway?)

It is usable in global scope.

> > Placing variable declarations in the beginning of the block increases
> > variable "LOC lifetime" so to speak and chances that it will be misused.
> > This is very low probability bug but still. Declaring variables right
> > before first use will make "LOC lifetime" smaller.
> 
> NAK it makes it very hard for a human (some of us are) to find
> the declaration.

What?

Which editor are you using?

Shift+3 with selection highlighting in vim works just fine.
I don't believe Emacs doesn't have an equivalent.

> Indeed putting them anywhere other that the top of a function
> or the top of a very short code block makes them hard to find.