From owner-freebsd-net Wed Nov 15 12:43:25 2000 Delivered-To: freebsd-net@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 5631637B4C5; Wed, 15 Nov 2000 12:43:23 -0800 (PST) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.0/8.11.0) with ESMTP id eAFKhMG68318; Wed, 15 Nov 2000 15:43:22 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200011152043.eAFKhMG68318@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Ruslan Ermilov Cc: Charles Mott , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: libalias: Incremental Update of Internet Checksum References: <200011150315.eAF3FIG60231@whizzo.transsys.com> <20001115100407.D36400@sunbay.com> <200011151436.eAFEaHG65417@whizzo.transsys.com> <20001115172435.A9724@sunbay.com> <200011151548.eAFFmJG66031@whizzo.transsys.com> <20001115180842.A11913@sunbay.com> In-reply-to: Your message of "Wed, 15 Nov 2000 18:08:42 +0200." <20001115180842.A11913@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Nov 2000 15:43:22 -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > If the above would be true that would mean that almost all implementations > of computing the checksum are wrong, i.e. they produce the value of 0x0000 > as a checksum when it should actually be 0xffff. That would also mean all > three RFCs: 1071, 1141 and 1624 are wrong. I can't believe that! But the thing is, both 0xffff and 0x0000 are the same value == 0. (One is negative zero, other other a positive zero.) I think the authors make an error when they conclude that the result of an addition can only be a negative zero rather than a positive zero, but in the end it doesn't really matter which representation of zero you use, because they are arithmetically equal. I think the authors of those RFCs probably had 2's complement CPUs in mind, and were thinking about commonly used emulations of 1's complement arithemetic operations. > My understanding of the one's complement sum is as follows: > > This is the sum (or an algorithm to compute such a sum), which produces > the RIGHT results for items represented in one's complement form, the form > in which negative numbers are represented by one's complements of a > positive number. > > You mentioned the books... Can you citate from one of these books that > states that 0xFFFF + 0x0001 in one's complement arithmetic is 0x0000 > rather than 0xFFFF? The correct result is 0x0001, since 0xffff is -0, and -0 + 1 == 1. 0xFFFE + 0x0001 == 0, because 0xFFFE is -1 and -1 + 1 == 0. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message