All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Robert P. J. Day" <rpjday@mindspring.com>
To: kernel-janitors@vger.kernel.org
Subject: Re: [KJ] memory zeroing macros
Date: Mon, 12 Feb 2007 08:59:22 +0000	[thread overview]
Message-ID: <Pine.LNX.4.64.0702120358040.19085@CPE00045a9c397f-CM001225dbafb6> (raw)
In-Reply-To: <Pine.LNX.4.64.0702101731480.6852@CPE00045a9c397f-CM001225dbafb6>

On Mon, 12 Feb 2007, Srdjan Todorovic wrote:

> On Sun, 11 Feb 2007, Greg KH wrote:
>
> > On Sun, Feb 11, 2007 at 03:34:34PM -0500, burns.ethan@gmail.com wrote:
> > > On Sun, Feb 11, 2007 at 04:32:11AM -0500, Robert P. J. Day wrote:
> > > > or maybe this really is just not worth the effort.  who knows?
> > >
> > > I don't think its worth the effort.  Changing the name on this
> > > wouldn't add any readability.  memset(dest, 0, len) is very
> > > clear, in my opinion.  Also, there's nothing really error prone
> > > about it...  I see no advantage.
> >
> > Not true at all, 0 and len get switched a lot accidentally.  See
> > the archives for times people have swept the kernel tree to fix
> > this issue up.
>
> I agree with you here, Greg, about accidentally switching the args
> to memset(). However just because someone (I've done this in the
> past, damn hard to debug since you don't expect to make this silly
> mistake) can do:
>
>   if (x = 0)  { }
>
> doesn't mean that we should discourage if statements.
>
> The macros from the wiki page add yet another set of
> macros/functions that someone has to learn.

i agree that those extra macros are overkill, except possibly in the
case of a simple memzero(), given that other developers seem to
re-invent it on an occasional basis.

but i'll leave this decision to someone else.

rday

-- 
====================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
====================================
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

      parent reply	other threads:[~2007-02-12  8:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-10 22:32 [KJ] memory zeroing macros Robert P. J. Day
2007-02-10 23:42 ` Alexey Dobriyan
2007-02-11  8:55 ` Robert P. J. Day
2007-02-11  9:24 ` Alexey Dobriyan
2007-02-11  9:32 ` Robert P. J. Day
2007-02-11 20:34 ` burns.ethan
2007-02-11 21:33 ` Greg KH
2007-02-12  1:51 ` Srdjan Todorovic
2007-02-12  4:43 ` Greg KH
2007-02-12  5:28 ` Richard Knutsson
2007-02-12  8:59 ` Robert P. J. Day [this message]

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=Pine.LNX.4.64.0702120358040.19085@CPE00045a9c397f-CM001225dbafb6 \
    --to=rpjday@mindspring.com \
    --cc=kernel-janitors@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.