Hacker News Reader

Comment by emodendroket | Hacker News Reader

I mean, is the answer really that hard? If the "refactor" would break the interface, you can't do it. Maybe you deprecate the old method and make a new one.

View on HN

How do they handle bug fixing though? What if one application wants a bug fixed, but another application is depending on the bug inadvertently?

You trivialize the broken usage.

The bug they fix is the bug that keeps the API contract intact. The first application gets its bug fixed, and the second application breaks because it was relying on a bug that didn't match the API contract. You program to an API, not to an implementation. The second application did the latter, and will therefore pay the price.

Well, sometimes, but the Windows philosophy is probably to introduce a shim so that an app relying on the broken functionality still works.

If you can afford to do that, it's nice to do it indeed. It can get messy and hairy quite quickly though.

It seems to me a lot of it boils down to "who gets impacted". If I have a bug in my kernel and a lot of apps are somehow relying on it, I need to be mindful of that and perhaps swallow the purity of the contract in order to provide a pragmatic fix.

Sure, it's not a strategy without costs and Microsoft goes to an extreme. But there's probably a middle way in there; if you're aware that tons of programs now depend on the buggy behavior you probably want to deal with it. But if you're working on Windows or the Linux kernel the tolerance for breaks is probably much lower.

That's not Linus' position. The "API contract" for the kernel is "we don't break userspace code," not "we don't break userspace code that follows the specs." He would bounce (and flame) the fix you're suggesting.

In other words, the ABI you have is the ABI that got used, not the ABI you thought you were building.

That sounds insane. Is it written somewhere besides a sporadic Linus rant? (e.g. somewhere here https://www.kernel.org/doc/html/latest/ etc.)

Introduce a new API.

That is a situation they work towards never happening, by never leaving a behavior change in the wild long enough for such a situation to develop.

If you look closely at the kernel code it is easy to find two or more syscalls that have names and behaviors that are very similar, but where one is recommended above all the others.This is because the older syscall(s) were found to be flawed.

But rather than break existing software, they introduce a new syscall that fixes said flaws and leave the old one intact and recommend that in the future software use the new syscall.

Reply on news.ycombinator.com