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: <20060723112005.GA6815@martell.zuzino.mipt.ru>
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/