public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
	Dave Jones <davej@redhat.com>,
	Arjan van de Ven <arjan@infradead.org>,
	Cyrill Gorcunov <gorcunov@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>
Subject: Re: memset as memzero
Date: Sun, 23 Sep 2007 20:46:39 +0200	[thread overview]
Message-ID: <20070923184639.GI10199@1wt.eu> (raw)
In-Reply-To: <alpine.LFD.0.999.0709230956040.16478@woody.linux-foundation.org>

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


  reply	other threads:[~2007-09-23 18:59 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-22  8:33 memset as memzero Cyrill Gorcunov
2007-09-22  8:48 ` Robert P. J. Day
2007-09-22  9:35   ` Cyrill Gorcunov
2007-09-22  9:55     ` Robert P. J. Day
2007-09-22 10:15       ` Cyrill Gorcunov
2007-09-22 19:46 ` Arjan van de Ven
2007-09-22 18:53   ` Linus Torvalds
2007-09-23 15:32     ` Dave Jones
2007-09-23 16:07       ` Arnaldo Carvalho de Melo
2007-09-23 17:05         ` Linus Torvalds
2007-09-23 18:46           ` Willy Tarreau [this message]
2007-09-23 16:33       ` Robert P. J. Day
2007-09-23 16:46         ` Arnaldo Carvalho de Melo
2007-09-22 19:25   ` Bernd Eckenfels
2007-09-22 20:37     ` Oleg Verych (nntp)
2007-09-22 19:32   ` Cyrill Gorcunov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070923184639.GI10199@1wt.eu \
    --to=w@1wt.eu \
    --cc=acme@ghostprotocols.net \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=davej@redhat.com \
    --cc=gorcunov@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox