2.10.3 unbatch bug and fix
Guy Harris
guy at sun.uucp
Fri Mar 21 04:45:19 AEST 1986
> In article <243 at micropro.UUCP> news at micropro.UUCP (USENET administrator) writes:
> >< while (strncmp(buf, "#! rnews ", 9)
> >< || strncmp(buf, "! rnews ", 8)) { /* kludge for bug */
> >---
> >> while (!strncmp(buf, "#! rnews ", 9)
> >> && !strncmp(buf, "! rnews ", 8)) { /* kludge for bug */
>
> Aren't these two the same by De Morgan's law?
No, the second is the complement of the first, by De Morgan's law. Using a
bastardized C notation, !(a || b) == (!a && !b), and therefore obviously
(a || b) != (!a && !b).
However, looking at the code to the 2.10.3 that comes with 4.3BSD beta, the
code around there reads
while (strncmp(buf, "#! rnews ", 9)) {
which means it's skipping over lines which do NOT begin with "#! rnews".
The original version, assuming it was a replacement for this line, skips
over lines which either don't begin with "#! rnews" or don't begin with "!
rnews", i.e. it never stops and skips over all lines. The replacement for
it, given the same assumption, skips over lines which both begin with "#!
rnews" and begin with "! rnews", i.e. it stops immediately. (If the first
and second tests are complements, since the second test is obviously always
FALSE the first test is obviously always TRUE.)
This is somewhat of an object lesson in Why Not To Treat "strcmp" As A
Function Returning A Boolean Value. It takes some effort to remember that
"strcmp(a, b)", treated as a Boolean value (i.e., 0/FALSE or non-0/TRUE) is
TRUE iff strings "a" and "b" are different. Now, since what we want is to
continue as long as the string neither begins with "#! rnews" or "! rnews",
we want
while (buf doesn't begin with "#! rnews"
&& buf doesn't begin with "! rnews") {
which translates as
while (strncmp(buf, "#! rnews", 9) != 0
&& strncmp(buf, "! rnews", 8) != 0)) {
since
string "a" <comparison op> string "b"
iff
strcmp(string "a", string "b") <comparison op> 0
--
Guy Harris
{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
guy at sun.arpa (yes, really)
More information about the Net.bugs
mailing list