Trivial, but important.
Somehow in the patching the bk tree somehow got two memset's to clear
new_client in it87_detect, normally while this would be bad, it would
not be critical.
However one of the two happens BEFORE the variable is set, and thus
things go badly.
--
1024D/E65A7801 Zephaniah E. Hull <[email protected]>
92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801
CCs of replies from mailing lists are requested.
>OK, fine. You're arguing semantics, though.
"arguing semantics" is not the same as "arguing nomenclature". My DI
was very good at arguing semantics. He had this funny idea that an
"unloaded" weapon was one that you had personally inspected and that
the semantic difference mattered. Something about not wanting to do
the paperwork of one of us killed someone with an unloaded weapon.
Most technical debates are ultimately about semantics, but that
doesn't mean that they are unimportant.
-- Shmuel Metz and Steve Sobol on ASR.
--- linux-2.5.69-mm6/drivers/i2c/chips/it87.c.orig 2003-05-17 03:37:19.000000000 -0400
+++ linux-2.5.69-mm6/drivers/i2c/chips/it87.c 2003-05-17 03:37:28.000000000 -0400
@@ -630,7 +630,6 @@
}
}
}
- memset (new_client, 0x00, sizeof(struct i2c_client) + sizeof(struct it87_data));
/* OK. For now, we presume we have a valid client. We now create the
client structure, even though we cannot fill it completely yet.
On Sun, May 18, 2003 at 06:21:50PM -0400, Zephaniah E. Hull wrote:
> Trivial, but important.
>
> Somehow in the patching the bk tree somehow got two memset's to clear
> new_client in it87_detect, normally while this would be bad, it would
> not be critical.
>
> However one of the two happens BEFORE the variable is set, and thus
> things go badly.
That's a wierd merge problem, sorry about that.
Applied.
greg k-h