On Tue, Jul 17, 2007 at 05:42:39PM -0400, Jeff Garzik wrote:
commit ae97fec3701a559929c3529e35417fab133a4d39
Author: Jeff Garzik [EMAIL PROTECTED]
Date: Tue Jul 17 01:08:29 2007 -0400
drivers/usb/misc/auerswald: fix status check, remove redundant check
1) We should only set
Hey, I appreciate it, but I really do have to warn you that I did this all
blind, and just meant for it to be a I think this kind of direction is
more productive thing. I'm not going to guarantee that it works at all.
Oh, understood, and I'm definitely planning on taking your patch as
On Wed, 18 Jul 2007, Roland Dreier wrote:
BTW, I noticed one interesting thing while starting on this cleanup.
I wanted to make sure that the generated code didn't change with the
first step, and I actually discovered that the patch below seems to
make the generated code *better*, maybe
Greg KH wrote:
On Tue, Jul 17, 2007 at 05:42:39PM -0400, Jeff Garzik wrote:
commit ae97fec3701a559929c3529e35417fab133a4d39
Author: Jeff Garzik [EMAIL PROTECTED]
Date: Tue Jul 17 01:08:29 2007 -0400
drivers/usb/misc/auerswald: fix status check, remove redundant check
1) We
On Wed, Jul 18, 2007 at 04:03:05PM -0400, Jeff Garzik wrote:
Greg KH wrote:
On Tue, Jul 17, 2007 at 05:42:39PM -0400, Jeff Garzik wrote:
commit ae97fec3701a559929c3529e35417fab133a4d39
Author: Jeff Garzik [EMAIL PROTECTED]
Date: Tue Jul 17 01:08:29 2007 -0400
Those may be used uninitialized warnings are annoying. So annoying
that kernel developers tune them out, and that occasionally hides
real bugs, as my past patches (and those below) indicate.
I included the full-length changelog below the diffstat, because
that is where the best explanation for
drivers/infiniband/hw/mthca/mthca_qp: kill uninit'd var warning
drivers/infiniband/hw/mthca/mthca_qp.c: In function
âmthca_tavor_post_sendâ:
drivers/infiniband/hw/mthca/mthca_qp.c:1594: warning: âf0â may be
used
uninitialized in this function
Roland Dreier wrote:
drivers/infiniband/hw/mthca/mthca_qp: kill uninit'd var warning
drivers/infiniband/hw/mthca/mthca_qp.c: In function
‘mthca_tavor_post_send’:
drivers/infiniband/hw/mthca/mthca_qp.c:1594: warning: ‘f0’ may be
used
Jeff Garzik wrote:
I don't buy that performance argument, in this case. You are already
dirtying the same cacheline with other variable initializations.
Or simply sitting in a CPU register for large stretches of function
runtime...
Jeff
-
To unsubscribe from this list: send the
On Tue, 17 Jul 2007 14:53:02 -0700
Roland Dreier [EMAIL PROTECTED] wrote:
drivers/infiniband/hw/mthca/mthca_qp: kill uninit'd var warning
drivers/infiniband/hw/mthca/mthca_qp.c: In function
__mthca_tavor_post_send__:
On Tue, 17 Jul 2007, Andrew Morton wrote:
(rofl, look at that mess: it was utterly impractical, unrealistic and
stupid for gcc to go and UTFify the compiler output. Sigh. LANG=C, guys).
Yeah, I absolutely *detest* how gcc does idiotic quoting just because you
happen to be in a UTF-8
I don't buy that performance argument, in this case. You are already
dirtying the same cacheline with other variable initializations.
Like I noted in the changeset description (hey, this is precisely why
I included it, so that we could have this discussion), IMO the flow of
control
On Tue, 17 Jul 2007, Roland Dreier wrote:
So setting a variable to something meaningless (guaranteeing that a
garbage value is used in case of a bug) just to shut up a warning makes
no sense -- it's no safer than leaving the code as is.
Wrong.
It's safer for two reasons:
- now
So setting a variable to something meaningless (guaranteeing that a
garbage value is used in case of a bug) just to shut up a warning makes
no sense -- it's no safer than leaving the code as is.
Wrong.
It's safer for two reasons:
- now everybody will see the *same*
Roland Dreier wrote:
In this case the code is basically
u32 x;
for (n = 0; cond; ++n) {
...
if (!n)
x = something;
...
}
if (n) {
...
use(x);
On Tue, 17 Jul 2007, Roland Dreier wrote:
I think this patch (on top of the previous one) actually makes the
code clearer
Quite frankly, calling this making the code clearer is a bit ridiculous.
That code still is absolute *crap* from a readability angle. It doesn't
follow any sane coding
Quite frankly, I don't quite understand where you get those enormous balls
you have, that you can then talk about how ugly it is to just add a = 0
that shuts up a compiler warning. That's the _least_ ugly part of the
whole damn function!
The clanking when I walk annoys people in the
On Tue, 17 Jul 2007, Roland Dreier wrote:
Anyway, here's a totally untested cleanup that compiles but probably
doesn't work, because I didn't check that I did the right thing with all
the pointer arithmetic (ie when I change wqe to a real structure pointer
instead of just a void
18 matches
Mail list logo
