[PATCH 1/3] auto, kbuild: flatten KBUILD_CFLAGS

[PATCH 1/3] auto, kbuild: flatten KBUILD_CFLAGS

[Alexey Dobriyan]

Make it slightly easier to see what compiler options are added and
removed (and not worry about column limit too!)

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
 Makefile | 22 +++++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/Makefile b/Makefile
index f836936fb4d8..10fcc64fcd1f 100644
--- a/Makefile
+++ b/Makefile
@@ -554,11 +554,23 @@ LINUXINCLUDE    := \
 		$(USERINCLUDE)
 
 KBUILD_AFLAGS   := -D__ASSEMBLY__ -fno-PIE
-KBUILD_CFLAGS   := -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs \
-		   -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE \
-		   -Werror=implicit-function-declaration -Werror=implicit-int \
-		   -Werror=return-type -Wno-format-security -funsigned-char \
-		   -std=gnu11
+
+KBUILD_CFLAGS :=
+KBUILD_CFLAGS += -std=gnu11
+KBUILD_CFLAGS += -fshort-wchar
+KBUILD_CFLAGS += -funsigned-char
+KBUILD_CFLAGS += -fno-common
+KBUILD_CFLAGS += -fno-PIE
+KBUILD_CFLAGS += -fno-strict-aliasing
+KBUILD_CFLAGS += -Wall
+KBUILD_CFLAGS += -Wundef
+KBUILD_CFLAGS += -Werror=implicit-function-declaration
+KBUILD_CFLAGS += -Werror=implicit-int
+KBUILD_CFLAGS += -Werror=return-type
+KBUILD_CFLAGS += -Werror=strict-prototypes
+KBUILD_CFLAGS += -Wno-format-security
+KBUILD_CFLAGS += -Wno-trigraphs
+
 KBUILD_CPPFLAGS := -D__KERNEL__
 KBUILD_RUSTFLAGS := $(rust_common_flags) \
 		    --target=$(objtree)/scripts/target.json \
-- 
2.40.1

[PATCH 2/3] auto: add "auto" keyword as alias for __auto_type

[Alexey Dobriyan]

It has similar semantics to "auto" keyword from a language
which can not be named on this mailing list, in particular:

	{
		int a;
		const auto b = a; // const char b = a;
		b = 1;	// compile error
	}
	{
		char a;
		auto b = a; // char b = a;
		// no integer promotions
		static_assert(sizeof(b) == 1);
	}
	{
		int a;
		const auto p = &a; // int *const p = &a;
		*p = 1;	// works because const is applied only to top-level
	}

It can be used to save on macroexpansion inside macro forests which
use typeof() somewhere deep enough. It is cool regardless.

Use "auto" in your code today!

gcc 5.1 supports __auto_type.

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
 Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index 10fcc64fcd1f..d316924a466a 100644
--- a/Makefile
+++ b/Makefile
@@ -570,6 +570,7 @@ KBUILD_CFLAGS += -Werror=return-type
 KBUILD_CFLAGS += -Werror=strict-prototypes
 KBUILD_CFLAGS += -Wno-format-security
 KBUILD_CFLAGS += -Wno-trigraphs
+KBUILD_CFLAGS += -Dauto=__auto_type
 
 KBUILD_CPPFLAGS := -D__KERNEL__
 KBUILD_RUSTFLAGS := $(rust_common_flags) \
-- 
2.40.1

[PATCH 3/3] auto, proc: use "auto" instead of quite chatty macros

[Alexey Dobriyan]

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
 fs/proc/inode.c | 32 ++++++++------------------------
 1 file changed, 8 insertions(+), 24 deletions(-)

diff --git a/fs/proc/inode.c b/fs/proc/inode.c
index f495fdb39151..88644891b876 100644
--- a/fs/proc/inode.c
+++ b/fs/proc/inode.c
@@ -309,9 +309,7 @@ static ssize_t proc_reg_read_iter(struct kiocb *iocb, struct iov_iter *iter)
 
 static ssize_t pde_read(struct proc_dir_entry *pde, struct file *file, char __user *buf, size_t count, loff_t *ppos)
 {
-	typeof_member(struct proc_ops, proc_read) read;
-
-	read = pde->proc_ops->proc_read;
+	auto read = pde->proc_ops->proc_read;
 	if (read)
 		return read(file, buf, count, ppos);
 	return -EIO;
@@ -333,9 +331,7 @@ static ssize_t proc_reg_read(struct file *file, char __user *buf, size_t count,
 
 static ssize_t pde_write(struct proc_dir_entry *pde, struct file *file, const char __user *buf, size_t count, loff_t *ppos)
 {
-	typeof_member(struct proc_ops, proc_write) write;
-
-	write = pde->proc_ops->proc_write;
+	auto write = pde->proc_ops->proc_write;
 	if (write)
 		return write(file, buf, count, ppos);
 	return -EIO;
@@ -357,9 +353,7 @@ static ssize_t proc_reg_write(struct file *file, const char __user *buf, size_t
 
 static __poll_t pde_poll(struct proc_dir_entry *pde, struct file *file, struct poll_table_struct *pts)
 {
-	typeof_member(struct proc_ops, proc_poll) poll;
-
-	poll = pde->proc_ops->proc_poll;
+	auto poll = pde->proc_ops->proc_poll;
 	if (poll)
 		return poll(file, pts);
 	return DEFAULT_POLLMASK;
@@ -381,9 +375,7 @@ static __poll_t proc_reg_poll(struct file *file, struct poll_table_struct *pts)
 
 static long pde_ioctl(struct proc_dir_entry *pde, struct file *file, unsigned int cmd, unsigned long arg)
 {
-	typeof_member(struct proc_ops, proc_ioctl) ioctl;
-
-	ioctl = pde->proc_ops->proc_ioctl;
+	auto ioctl = pde->proc_ops->proc_ioctl;
 	if (ioctl)
 		return ioctl(file, cmd, arg);
 	return -ENOTTY;
@@ -406,9 +398,7 @@ static long proc_reg_unlocked_ioctl(struct file *file, unsigned int cmd, unsigne
 #ifdef CONFIG_COMPAT
 static long pde_compat_ioctl(struct proc_dir_entry *pde, struct file *file, unsigned int cmd, unsigned long arg)
 {
-	typeof_member(struct proc_ops, proc_compat_ioctl) compat_ioctl;
-
-	compat_ioctl = pde->proc_ops->proc_compat_ioctl;
+	auto compat_ioctl = pde->proc_ops->proc_compat_ioctl;
 	if (compat_ioctl)
 		return compat_ioctl(file, cmd, arg);
 	return -ENOTTY;
@@ -430,9 +420,7 @@ static long proc_reg_compat_ioctl(struct file *file, unsigned int cmd, unsigned
 
 static int pde_mmap(struct proc_dir_entry *pde, struct file *file, struct vm_area_struct *vma)
 {
-	typeof_member(struct proc_ops, proc_mmap) mmap;
-
-	mmap = pde->proc_ops->proc_mmap;
+	auto mmap = pde->proc_ops->proc_mmap;
 	if (mmap)
 		return mmap(file, vma);
 	return -EIO;
@@ -457,9 +445,7 @@ pde_get_unmapped_area(struct proc_dir_entry *pde, struct file *file, unsigned lo
 			   unsigned long len, unsigned long pgoff,
 			   unsigned long flags)
 {
-	typeof_member(struct proc_ops, proc_get_unmapped_area) get_area;
-
-	get_area = pde->proc_ops->proc_get_unmapped_area;
+	auto get_area = pde->proc_ops->proc_get_unmapped_area;
 #ifdef CONFIG_MMU
 	if (!get_area)
 		get_area = current->mm->get_unmapped_area;
@@ -555,9 +541,7 @@ static int proc_reg_release(struct inode *inode, struct file *file)
 	struct pde_opener *pdeo;
 
 	if (pde_is_permanent(pde)) {
-		typeof_member(struct proc_ops, proc_release) release;
-
-		release = pde->proc_ops->proc_release;
+		auto release = pde->proc_ops->proc_release;
 		if (release) {
 			return release(inode, file);
 		}
-- 
2.40.1

Re: [PATCH 2/3] auto: add "auto" keyword as alias for __auto_type

[Andrew Morton]

On Tue, 16 May 2023 19:49:46 +0300 Alexey Dobriyan <adobriyan@gmail.com> wrote:

> It has similar semantics to "auto" keyword from a language
> which can not be named on this mailing list, in particular:

Huh, 20 years ago C's auto meant "automatic variable".  ie, stored on
the stack.  It was never needed because that's the default, unless you
used `register', which gave the false impression that you're being
faster.

> 	{
> 		int a;
> 		const auto b = a; // const char b = a;

I assume that should be "const int b = a".

> 		b = 1;	// compile error
> 	}
> 	{
> 		char a;
> 		auto b = a; // char b = a;
> 		// no integer promotions
> 		static_assert(sizeof(b) == 1);
> 	}
> 	{
> 		int a;
> 		const auto p = &a; // int *const p = &a;
> 		*p = 1;	// works because const is applied only to top-level
> 	}
> 
> It can be used to save on macroexpansion inside macro forests which
> use typeof() somewhere deep enough. It is cool regardless.
> 
> Use "auto" in your code today!
> 
> gcc 5.1 supports __auto_type.
> 
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
> ---
>  Makefile | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Makefile b/Makefile
> index 10fcc64fcd1f..d316924a466a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -570,6 +570,7 @@ KBUILD_CFLAGS += -Werror=return-type
>  KBUILD_CFLAGS += -Werror=strict-prototypes
>  KBUILD_CFLAGS += -Wno-format-security
>  KBUILD_CFLAGS += -Wno-trigraphs
> +KBUILD_CFLAGS += -Dauto=__auto_type
>  
>  KBUILD_CPPFLAGS := -D__KERNEL__
>  KBUILD_RUSTFLAGS := $(rust_common_flags) \

Examples at https://lkml.kernel.org/r/20230516164947.86543-3-adobriyan@gmail.com

It is pretty cool and could get used a lot.  Cc Linus for his thoughts?

Re: [PATCH 2/3] auto: add "auto" keyword as alias for __auto_type

[Linus Torvalds]

On Tue, May 16, 2023 at 2:39 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> It is pretty cool and could get used a lot.  Cc Linus for his thoughts?

I'm not against it, although I'm also not convinced we need / want to
convert existing users of typeof().

The reason we use typeof is that that has always worked in gcc, and
__auto_type is relatively "new" in contrast.

But we require at least gcc-5.1 anyway, so it should be fine.

Note that mindless conversions can be dangerous: using "typeof(x)" in
macros may end up feeling a bit verbose, and "auto" can appear nicer,
but the auto use needs to be *very* careful about integer promotions.

For example, in

  #define WRAPPER(c) do { \
        typeof(c) __c = (c);
        ...

it is very obvious what the type is.

But while using

   #define WRAPPER(c) do { \
        auto __c = (c);

gives you the same result with less redundancy (no need to state 'c'
twice), if you *ever* then happen to make that an integer expression
that is not *just* 'c' - even a trivial one - suddenly 'var' goes from
'char' to 'int' because of the integer expression.

So __auto_type (and I agree that if we use it, we should probably just
wrap it in an 'auto' #define, since the legacy 'auto' keyword is
useless) can result in simpler and more obvious code, but it can also
lead to subtle type issues that are easy to then overlook.

The above is not an argument against 'auto', but it's one reason I'm
not convinced some mindless "convert existing uses of __typeof__" is a
good idea even if it might make some of them more legible.

But I have nothing against people starting to use it in new code.

And no, I don't think we should do that

    KBUILD_CFLAGS += -Dauto=__auto_type

in the Makefile as Alexey suggests.

I think this is a 'compiler_types.h' kind of thing, and goes along
with all the other "simplied syntax" things we do (ie we redefine
'inline', we add "__weak" etc etc etc).

                  Linus

Re: [PATCH 2/3] auto: add "auto" keyword as alias for __auto_type

[Alexey Dobriyan]

On Tue, May 16, 2023 at 04:18:59PM -0700, Linus Torvalds wrote:
> On Tue, May 16, 2023 at 2:39 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > It is pretty cool and could get used a lot.  Cc Linus for his thoughts?
> 
> I'm not against it, although I'm also not convinced we need / want to
> convert existing users of typeof().
> 
> The reason we use typeof is that that has always worked in gcc, and
> __auto_type is relatively "new" in contrast.
> 
> But we require at least gcc-5.1 anyway, so it should be fine.
> 
> Note that mindless conversions can be dangerous: using "typeof(x)" in
> macros may end up feeling a bit verbose, and "auto" can appear nicer,
> but the auto use needs to be *very* careful about integer promotions.
> 
> For example, in
> 
>   #define WRAPPER(c) do { \
>         typeof(c) __c = (c);
>         ...
> 
> it is very obvious what the type is.
> 
> But while using
> 
>    #define WRAPPER(c) do { \
>         auto __c = (c);
> 
> gives you the same result with less redundancy (no need to state 'c'
> twice), if you *ever* then happen to make that an integer expression
> that is not *just* 'c' - even a trivial one - suddenly 'var' goes from
> 'char' to 'int' because of the integer expression.
> 
> So __auto_type (and I agree that if we use it, we should probably just
> wrap it in an 'auto' #define, since the legacy 'auto' keyword is
> useless) can result in simpler and more obvious code, but it can also
> lead to subtle type issues that are easy to then overlook.
> 
> The above is not an argument against 'auto', but it's one reason I'm
> not convinced some mindless "convert existing uses of __typeof__" is a
> good idea even if it might make some of them more legible.
> 
> But I have nothing against people starting to use it in new code.
> 
> And no, I don't think we should do that
> 
>     KBUILD_CFLAGS += -Dauto=__auto_type
> 
> in the Makefile as Alexey suggests.
> 
> I think this is a 'compiler_types.h' kind of thing, and goes along
> with all the other "simplied syntax" things we do (ie we redefine
> 'inline', we add "__weak" etc etc etc).

Sure. I thought about where to put it in the filesystem under nice name
but somehow completely forgot about compiler_types.h

I'll probably go through core headers at least and start conversion
myself. Expect version 2 soon.