[PATCH] lib/vsprintf: use bool for local decode variable

[PATCH] lib/vsprintf: use bool for local decode variable

[Thorsten Blum]

The local variable 'decode' is only used as a boolean value - change its
data type from int to bool accordingly.

Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
 lib/vsprintf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 800b8ac49f53..9f359b31c8d1 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1107,7 +1107,7 @@ char *resource_string(char *buf, char *end, struct resource *res,
 		     2*RSRC_BUF_SIZE + FLAG_BUF_SIZE + RAW_BUF_SIZE)];
 
 	char *p = sym, *pend = sym + sizeof(sym);
-	int decode = (fmt[0] == 'R') ? 1 : 0;
+	bool decode = fmt[0] == 'R';
 	const struct printf_spec *specp;
 
 	if (check_pointer(&buf, end, res, spec))
@@ -1132,7 +1132,7 @@ char *resource_string(char *buf, char *end, struct resource *res,
 	} else {
 		p = string_nocheck(p, pend, "??? ", str_spec);
 		specp = &mem_spec;
-		decode = 0;
+		decode = false;
 	}
 	if (decode && res->flags & IORESOURCE_UNSET) {
 		p = string_nocheck(p, pend, "size ", str_spec);

Re: [PATCH] lib/vsprintf: use bool for local decode variable

[David Laight]

On Tue,  7 Apr 2026 20:18:36 +0200
Thorsten Blum <thorsten.blum@linux.dev> wrote:

> The local variable 'decode' is only used as a boolean value - change its
> data type from int to bool accordingly.

Hopefully the compiler actually does:
	int decode = fmt[0];
and then compares against 'R' later on.
But this change ought to make absolutely no difference to the code.

	David

> 
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
>  lib/vsprintf.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 800b8ac49f53..9f359b31c8d1 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -1107,7 +1107,7 @@ char *resource_string(char *buf, char *end, struct resource *res,
>  		     2*RSRC_BUF_SIZE + FLAG_BUF_SIZE + RAW_BUF_SIZE)];
>  
>  	char *p = sym, *pend = sym + sizeof(sym);
> -	int decode = (fmt[0] == 'R') ? 1 : 0;
> +	bool decode = fmt[0] == 'R';
>  	const struct printf_spec *specp;
>  
>  	if (check_pointer(&buf, end, res, spec))
> @@ -1132,7 +1132,7 @@ char *resource_string(char *buf, char *end, struct resource *res,
>  	} else {
>  		p = string_nocheck(p, pend, "??? ", str_spec);
>  		specp = &mem_spec;
> -		decode = 0;
> +		decode = false;
>  	}
>  	if (decode && res->flags & IORESOURCE_UNSET) {
>  		p = string_nocheck(p, pend, "size ", str_spec);
> 

Re: [PATCH] lib/vsprintf: use bool for local decode variable

[Petr Mladek]

On Tue 2026-04-07 20:18:36, Thorsten Blum wrote:
> The local variable 'decode' is only used as a boolean value - change its
> data type from int to bool accordingly.
> 
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -1107,7 +1107,7 @@ char *resource_string(char *buf, char *end, struct resource *res,
>  		     2*RSRC_BUF_SIZE + FLAG_BUF_SIZE + RAW_BUF_SIZE)];
>  
>  	char *p = sym, *pend = sym + sizeof(sym);
> -	int decode = (fmt[0] == 'R') ? 1 : 0;
> +	bool decode = fmt[0] == 'R';
>  	const struct printf_spec *specp;
>  
>  	if (check_pointer(&buf, end, res, spec))
> @@ -1132,7 +1132,7 @@ char *resource_string(char *buf, char *end, struct resource *res,
>  	} else {
>  		p = string_nocheck(p, pend, "??? ", str_spec);
>  		specp = &mem_spec;
> -		decode = 0;
> +		decode = false;
>  	}
>  	if (decode && res->flags & IORESOURCE_UNSET) {
>  		p = string_nocheck(p, pend, "size ", str_spec);

I have mixed feeling about this patch. I agree that it might slightly
improve code readability. But cosmetic changes are usually about
personal preferences and often just pollute code history.

IMHO, this is really just about "code readability" vs "code history
pollution" problem. I believe that compilers would handle both variants
the same way.

As I said, I agree that this this slightly improves the code
readability and it is trivial. So I am going to wait few more
days and take this patch unless there is a strong push back
from others.

Reviewed-by: Petr Mladek <pmladek@suse.com>

Best Regards,
Petr