upvote
Breaking down the oddity on 0x0000 and 0xFFFF further, it stems from this special behavior per the RFCs https://www.rfc-editor.org/rfc/rfc1122#page-29:~:text=is%20v...:

> Unlike the TCP checksum, the UDP checksum is optional; the value zero is transmitted in the checksum field of a UDP header to indicate the absence of a checksum. If the transmitter really calculates a UDP checksum of zero, it must transmit the checksum as all 1's (65535). No special action is required at the receiver, since zero and 65535 are equivalent in 1's complement arithmetic.

Using 0x0000 and 0xFFFF as special values via 1's complement creates the error, only for these 2 specific values, when 2's complement logic is used to calculate.

reply
In my university times I wrote a library (to help with some homework we gave students) that calculated the CRC32 for ethernet.

Which worked well unless compiled with `strict-aliasing` gcc optimizations enabled...

Just writing UDP RFC compliant code doesn't protect you from running into annoying behavior with your programming language of choice...

reply
> Which worked well unless compiled with `strict-aliasing` gcc optimizations enabled

I can't imagine enabling this by default instead of opting in with __restrict or equivalent. Just so many things that could go wrong if every little piece of code was not written with aliasing in mind.

reply
I love Wube's FFFs. I wish more devs would do it; not just a devlog, but really going into the nitty-gritty of how some systems work.
reply