linux-kernel - Re: [PATCH] drivers: Conversions from kmalloc+memset to k(z|c)alloc.

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]

Message-Id: <200607232024.43237.mb@bu3sch.de>
Date:	Sun, 23 Jul 2006 20:24:43 +0200
From:	Michael Buesch <mb@...sch.de>
To:	Tomasz Kłoczko <kloczek@...y.mif.pg.gda.pl>
Cc:	linux-kernel@...r.kernel.org, Alexey Dobriyan <adobriyan@...il.com>
Subject: Re: [PATCH] drivers: Conversions from kmalloc+memset to k(z|c)alloc.

On Sunday 23 July 2006 19:55, Tomasz Kłoczko wrote:
> On Sun, 23 Jul 2006, Alexey Dobriyan wrote:
> [..]
> >> Again: using indent mainly will mean only one time massive changes.
> >
> > True, 180M(!) of them.
> 
> ~160M.
> And this is so huge now because seems there is no obligation use common 
> format .. all is formated using hands/mind/difftent editors autoformaters.
> 
> >> After
> >> this ident can be runed for example by Linus just before make release
> >> and/or partial release.
> >
> > ~4M per run.
> 
> If patch submmitter will use formating tool and it will add it will statr 
> work on formated source tree it will be 0M per run.
> 
> >>> scripts/Lindent exists and gets used, but it is not perfect.
> >
> > Correction: GNU indent exists and gets used, but it is not perfect.
> 
> Yes .. and produce by Lindent ~160MB patch it excelent proof how offent is 
> is used now :>
> (please stop this crap "argumentation" :>)

Yeah, please stop it.
Did you actually _look_ at what indent does to code sometimes?
It sometimes (often?) renders perfectly readable code into a
huge blob of crap.

Face reality. The linux kernel is following the general codingstyle
very well already. I don't think there is need to improve the current
codebase for non-existent codingstyle issues. And we already review
new code for codingstyle issues, so the codebase remains clean.

Look at other projects with horrible codingstyle problems
and suggest solutions to their _real_ issues. *cough*kde*cough*

-- 
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/