On Fri, Dec 08, 2023 at 03:56:27PM +0000, David Laight wrote: > > You add them as natural numbers. If there is no carry and result > > fits into N bits, that's it. If there is carry, you add it to > > the lower N bits of sum. > > > > Discussion of properties of that operation is present e.g. in > > RFC1071, titled "Computing the Internet Checksum". > > > > May I politely suggest that some basic understanding of the > > arithmetics involved might be useful for this discussion? > > Well 0x0000 is +0 and 0xffff is -0, mathematically they are (mostly) > equal. As representations of signed integers they are. However, the origin of operation in question is irrelevant. Again, read the fucking RFC. > I bet that ICMP response (with id == 0 and seq == 0) is the only > place it is possible to get an ip-checksum of a zero buffer. > So it will be pretty moot for copy+checksum with can return 0xffff > (or lots of other values) for an all-zero buffer. Egads... Your bets are your business; you *still* have not bothered to look at the callers of these primitives. Given the accuracy of your guesses so far, pardon me for treating any "I bet"/"it stands for reason"/etc. coming from you as empty handwaving. > In terms of copy+checksum returning an error, why not reduce the > 32bit wcsum once (to 17 bits) and return -1 (or ~0u) on error? > Much simpler than your patch and it won't have the lurking problem > of the result being assigned to a 32bit variable. In case you have somehow missed it, quite a few of the affected places are in assembler. The same would apply to added code that would do this reduction. Which is going to be considerably less trivial than the changes done in that patch.
