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] [day] [month] [year] [list]
Message-ID: <20070923184639.GI10199@1wt.eu>
Date:	Sun, 23 Sep 2007 20:46:39 +0200
From:	Willy Tarreau <w@....eu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Dave Jones <davej@...hat.com>,
	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

On Sun, Sep 23, 2007 at 10:05:05AM -0700, Linus Torvalds wrote:
> 
> 
> On Sun, 23 Sep 2007, Arnaldo Carvalho de Melo wrote:
> > 
> > bzero! That is it, its nothing new, just a sane name to something [..]
> 
> No, please no!
> 
> The BSD memory functions are nasty. If you do bzero, you logically should 
> do the others too, and they are way inferior to the standard ones. Let's 
> not go there.
> 
> Besides, if we want to avoid mistakes, I would suggest going to a much 
> higher level. Ie more along the lines of also fixing the size and 
> alignment, and using something like
> 
> 	#define memclear(p) memset(p, 0, sizeof(*(p)))

I don't like it when macros magically do sizeof(*p), because people often
think that the macro is smarter than it really is, and you commonly end
up with code looking like this :

     char *p;
     ...
     p = kmalloc(n);
     ...
     memclear(p);

This can happen for instance when replacing a stack-allocated buffer
with a malloc because it became too big for the stack. Such a mistake
is *very hard* to detect by human eye, while having "sizeof(*p)" in
the same function as "char *p" will trigger some automatisms in most
readers' brains.

> because if you actually do something like
> 
> 	git grep 'memset.*,[ 	]*0[ 	]*,'
> 
> (those [..] things contatain a space and a tab), you'll see that a *lot* 
> of them share that pattern. 

At least current code is still greppable for such usages. Doing too
much magics with macros often harms debugging. I could agree with
having a macro to force the pattern to '0', but not to force the size.

> Not that I think it's really worth it.

I don't think either.

Willy

-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ