All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Love <rml@tech9.net>
To: Andreas Dilger <adilger@turbolabs.com>
Cc: "René Scharfe" <l.s.r@web.de>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Linus Torvalds" <torvalds@transmeta.com>,
	"Alan Cox" <alan@redhat.com>
Subject: Re: [PATCH] random.c bugfix
Date: 27 Oct 2001 02:35:55 -0400	[thread overview]
Message-ID: <1004164556.3274.14.camel@phantasy> (raw)
In-Reply-To: <20011027002142.D23590@turbolinux.com>
In-Reply-To: <m15xL0J-007qTxC@smtp.web.de>  <20011027002142.D23590@turbolinux.com>

On Sat, 2001-10-27 at 02:21, Andreas Dilger wrote:
> OK, my bad.  At least the random variable-name cleanups let you SEE where
> we are supposed to be using word sizes and byte sizes.  Even you were
> confused about it ;-)

I went over your original patch good; I am surprised I missed this. :/
Nonetheless, only with the new cleanups could anyone spot this.

> Well, this is a matter of taste.  With my code, it is correct regardless
> of how tmp is declared, while with your code you assume tmp is TMP_BUF_SIZE
> words, and that it is declared with a 4-byte type.  Both ways are resolved
> at compile time, so using "sizeof(tmp)/4" or "sizeof(tmp)*8" doesn't add
> any run-time overhead.

I think I prefer your sizeof() method, if for nothing else but that we
can keep it consistent -- we can always take the sizeof a variable and
not everything has its size in a define.

Furthermore, sizeof(tmp) certainly means "size of the variable temp"
while TMP_BUF_SIZE could be the size of anything related to tmp -- the
buffer it points to (if it were a pointer), a buffer in it (if it were a
struct), etc.  Since it all compiles to the same, it is not a huge
issue.  Just my two bits...

> I don't have a strong opinion either way, if Linus and/or Alan have a
> preference to do it one way or the other.

...but I'm not Alan or Linus ;)

	Robert Love


  reply	other threads:[~2001-10-27  6:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-27  4:21 [PATCH] random.c bugfix René Scharfe
2001-10-27  6:21 ` Andreas Dilger
2001-10-27  6:35   ` Robert Love [this message]
2001-10-28 23:57   ` Horst von Brand
2001-10-29  5:37     ` Andreas Dilger
2001-10-29 16:15       ` Horst von Brand
2001-10-29 16:58         ` Oliver Xymoron
2001-10-29 23:39           ` Andreas Dilger
2001-10-30  0:23             ` Oliver Xymoron
2001-10-30  3:50               ` Andreas Dilger
2001-10-30 16:07                 ` Theodore Tso
2001-10-31  6:19                   ` Andreas Dilger
2001-10-31 14:42                     ` Oliver Xymoron
2001-10-30  4:49               ` Andreas Dilger
2001-10-29  5:46     ` [PATCH] MAJOR " Andreas Dilger

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=1004164556.3274.14.camel@phantasy \
    --to=rml@tech9.net \
    --cc=adilger@turbolabs.com \
    --cc=alan@redhat.com \
    --cc=l.s.r@web.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /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.