linux-kernel - Re: [PATCH 1/4] proc/bootconfig: Fix to use correct quotes for value

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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 15 Jun 2020 16:12:21 -0700
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Joe Perches <joe@...ches.com>,
        Masami Hiramatsu <mhiramat@...nel.org>, stable@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/4] proc/bootconfig: Fix to use correct quotes for value

On 6/15/20 3:42 PM, Steven Rostedt wrote:
> On Mon, 15 Jun 2020 15:30:41 -0700
> Randy Dunlap <rdunlap@...radead.org> wrote:
> 
>>>> Please don't infect kernel sources with that style oddity.  
>>>
>>> What do you mean? It's already "infected" all over the kernel, (has
>>> been for years!) and I kinda like it. It makes reading variables much
>>> easier on the eyes, and as I get older, that means a lot more ;-)  
>>
>> Yeah, there is some infection, more in some places than others,
>> but I agree with Joe -- it's not needed or wanted by some of us.
> 
> We all have preferences. But for code that I need to review, I prefer
> it.
> 
> Why would you be bothered by it? Which is easier on the eyes to read
> variables?

"to read variables"?  I mostly read code, not variables.

>  	struct xbc_node *leaf, *vnode;
>  	const char *val;
> 	char q;
>  	char *key, *end = dst + size;
>  	int ret = 0;
> 
> or
> 
>  	struct xbc_node *leaf, *vnode;
>  	char *key, *end = dst + size;
>  	const char *val;
> 	char q;
>  	int ret = 0;
> 
> ?

But yes, we all have preferences. For data declaration, mine is more like
order of use or some grouping having to do with locality.

cheers.

-- 
~Randy
Reported-by: Randy Dunlap <rdunlap@...radead.org>