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
| ||
|
Date: Sun, 23 Jul 2006 15:20:05 +0400 From: Alexey Dobriyan <adobriyan@...il.com> To: Tomasz Kłoczko <kloczek@...y.mif.pg.gda.pl> Cc: linux-kernel@...r.kernel.org Subject: Re: [PATCH] drivers: Conversions from kmalloc+memset to k(z|c)alloc. [CC list trimmed] On Sat, Jul 22, 2006 at 10:55:55PM +0200, Tomasz Kłoczko wrote: > On Sat, 22 Jul 2006, Jeff Garzik wrote: > >Tomasz Kłoczko wrote: > >>Moment .. are you want to say something like "keep commont coding style > >>can't be maintained by tool" ? > >>Even if indent watches on to small coding style emenets still I don't see > >>why using this tool isn't one of the current ement of release procedure > >>(?). > > > >indent isn't perfect, _especially_ where C99 comes into the picture. > > Again: is in this case "isn't perfect" mean "it does not make all what we > want" ? If yes still I don't see why not use indent + some other tool or > if you will show real example where it does something badady (like now > for checking code syntax is used compiler and some other tools like > sparse). > > >And running indent across the tree pre-release would (a) create a ton of > >noise before each release, and (b) undo perfectly valid, readable > >formatting. > > Committing all this "noise" will plug all this thing and allow reve most > of content Documentation/CodingStyle document. > Is it not wort stop all questions/discuss/flames on this subject ? Yes, it's better to stop this thread. Because you haven't done your homework and advocating procedure which will create massive spurious changes every time it's applied. If you have math background: Lindent \cdot Lindent \neq Lindent pretty often. If you don't, see below. > Again: using indent mainly will mean only one time massive changes. True, 180M(!) of them. > After > this ident can be runed for example by Linus just before make release > and/or partial release. ~4M 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. Last time I checked BSD indent don't have some option Lindent use. forgot which. > Again: anywhere are listed/was posted list of "not perfect" examples ? OOhhhh, please do find . -type f -name '*.[ch]' | xargs ./scripts/Lindent on any large C codebase. > And/or: what does it mean in this case "not perfect" ? > Show this for > allow start work on fix indent by other people (if all cases will be resul > of some bugs in this tool). Start fixing indent(1) if you're serious about all this. There are _plenty_ of C code flying around. - 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/
Powered by blists - more mailing lists