linux-kernel - Re: memset as memzero

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 Sep 2007 13:46:22 -0300
From:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
To:	"Robert P. J. Day" <rpjday@...dspring.com>
Cc:	Dave Jones <davej@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Cyrill Gorcunov <gorcunov@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: memset as memzero

Em Sun, Sep 23, 2007 at 12:33:13PM -0400, Robert P. J. Day escreveu:
> On Sun, 23 Sep 2007, Dave Jones wrote:
> 
> > There is one useful argument for memzero (or bzero to give it its
> > proper name), and that's that it's impossible to screw up. I'm still
> > amazed at how many times I see
> >
> > 	memset (x,size,0);
> >
> > in various code. So much so, that my editor highlights it now to
> > spot it during code review.  As does my mail client.  To be on the
> > safe side, I also have a cron job grepping for it in my
> > ~/Mail/commits for all the projects I'm interested in.
> 
>   taking a step back, regardless of what constitutes a sane versus
> not-sane definition of a useful macro, i think a lot of the content of
> kernel.h could be moved out of there and put in a more appropriate
> header file called, say, macros.h.
> 
>   the first comment in kernel.h claims that
> 
> /*
>  * 'kernel.h' contains some often-used function prototypes etc
>  */
> 
> but there's buckets more stuff in there than just some function
> prototypes.  macros for type limits, alignment, array sizes, rounding,
> and on and on.  and as for those prototypes, is there any reason that
> kernel.h includes them explicitly for the contents of lib/vsprintf.c
> rather than just including, say, a hypothetical vsprintf.h?  just
> curious.
> 
> in any case, it would seem that kernel.h could stand a good cleaning.
> it give the impression of just being an arbitrary dumping ground when
> folks can't figure out where to put something.

In an ideal world kernel.h has no place, I guess. I guess too that
janitors could make the world ideal in that respect. Keep moving things
from there to the right place. Don't do it every other day tho. People
find it annoying.

- Arnaldo
-
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/