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:	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