A fifteen year old TCP bug? (opens in new tab)

I agree - but it's funny that there's only a handful of comments. You just can't have an uninformed rant with such technical correctness (the best kind of correctness)!

.. and comes from a cool hackerish domain (42.org)

I know of one commercial Smalltalk UI bug that persisted 12 years -- being reported all the while. To be fair, it was a very tricky low-level race condition, very hard to reproduce, though very serious. (Unhandled exception in the bowels of the UI library. Boom! Application goes down.) Still, the attitude of the vendor was just unbelievable from the POV of the customer. After dozens of reports, hundreds of messages, numerous pieces of documentation, it still took 12 years for engineers to even start thinking it was something besides user error -- even though multiple customers were reporting it. (I know because I worked for 3 of them!) There is a huge perceptual wall there. I know because I used to work for the vendor. I know how apparent this bug is at a production shop and how opaque it appears from inside the vendor's camp. (And despite my being from inside, I still got the "user error" chant!)

EDIT: Oh, and I know of another UI bug that's been in their system for about 8 years. It's a Smalltalk newbie classic -- shoving non-identity keys into an IdentityDictionary. I could describe what it is to a Smalltalker in 2 sentences, and they could then find it and fix it. This vendor seems to have the same attitude about this bug, so I've already learned my lesson. They can keep their damn bug!

It's a working fix, but isn't the proper fix. The real issue is the size difference of the long type for 32 and 64-bit architectures. Bruce Evans doesn't explicitly mention this fact, but it's the core of his reasoning.

Since long is 64-bits on 64-bit architecture, and 32 on 32-bit architecture. This is the reason that 0xffffffff is showing up as a non-negative number on the 64-bit machine, but shows up as negative on the 32-bit.

Changing the type to int(which is 32 bits long on both x86 and x64), while it does break 16-bit systems(which don't exist anymore), fixes this completely by removing the x86 and x64 behavior differences with the long type.

The two style issues that he mentions are easily fixed by moving the variable declaration to the top of the function and initializing it there. However, these may be forced by the function structure due to the gotos present in the code...

You have to do this if you want your codebase to get better over time rather than worse over time.

What he's doing seems useful to the project. There's no better time to get it right. I'm just surprised he's willing to expend so much effort communicating instead of just fixing the patch.

I noticed that C programmers tend to use macros for things where (possibly non-exported) inline functions would make more sense. Why is that? Are they in the habit of building the OS with all optimizations off? Or is it that they're being used as poor man's generic function?

I believe the comment above was meant as a response to the "The response to the bug report looks depressingly typical" comment elsewhere in this thread.

It took me a minute to sort that out ("hmm, why is he referencing Bruce Evans?"), so I thought I'd mention it for anyone else trying to follow.

No, actually it's not public domain. The 19th edition was printed and released in 2005. Pearson looks like it actively tries to protect it's copyrights to the series as well: http://www.foo.be/docs/TCPIP-Illustrated-1/

Its not because if you are a FreeBSD developer it is already assumed that you own every copy of Steven's books next to the shrine of him in your basement. So linking to a digital scan is not infringement its just convenience.

Wouldn't that be fair use? Do you have issue with the content being posted, or the fact that it's scanned?

What people say that?

Care to elaborate? Unlike signed ones, unsigned integral types at least have well-defined behavior on shifting and overflow. (I'm speaking in terms C specifically here, of course.)

I wouldn't say they are evil. In fact, both signed and unsigned are the same--the only difference is the "pain point" (the place where you subtract 1 and your world breaks) is in a different spot. 0 for unsigned, INT_MIN for signed. Both are perfectly fine as long as you stay in their good range.

A coworker of mine was just bit badly by Java's insistence that unsigned types are so evil that the language shouldn't have them. He calculated a 32-bit hash, but since the ints are all signed, he took the absolute value before the modulo with the hash table size. That's all well and good, but abs(-2147483648) is still -2147483648 in 32-bit two's complement arithmetic.

I'm sure I don't need to point out that this particular problem had nothing to do with unsigned types (they were signed!). A better rule of thumb is: never use "long" in C/C++ unless you really don't care whether it's 32 or 64 bits.

Maybe, if you could trick the server (64-bit FreeBSD) into connecting to sockets open on 32-bit FreeBSD machines. I can't think of any common services that would be susceptible to this (they would normally be susceptible to being tricked into opening other kinds of long-standing connections, too, which is just as good for DoS).