I feel like preventing illegal writes to protected memory is less "breaking user space" and more "protecting all space".

This is like arguing to allow the guy who can't drive and just pin-balls his way down the freeway bouncing of other cars, because to prevent him from driving would be to take away his personal freedoms.

There was no conceivable version of a road system where that behavior would ever be okay. However, it's not only conceivable but, apparently standard practice in systems programming, to "Try and Fail" instead of "Only Proceed if allowed".

So, if we want a tortured metaphor what JVM is doing is like trying to pass a turnstile to see if the pass is still valid so that on the happy path it saves the extra check. Now Apple decided that instead of just showing a red X and letting you buy a new pass, in the future you get shot in the back of the head if you try with an invalid pass.

> There was no conceivable version of a road system where that behavior would ever be okay.

That doesn't mean it doesn't happen.

Are you suggesting that the approach taken here was at one point a documented acceptable approach, according to Apple?

According to UNIX, which MacOS is certified of being.

Can't find it in SuSv3 (but that's thing, like all UNIX manuals, is a monstrosity): https://pubs.opengroup.org/onlinepubs/9299959899/toc.pdf

Linux did break adobe flash when it used memmove like memcopy after fixing a kernel bug. Can't think of any other examples though.

Well, everyone breaks Adobe Flash... that's the whispered exception at the end of the rule: "don't break userspace and then blame the user (unless that user is Adobe Flash... F--- Adobe Flash)" ;P.

AFAIR it was glibc change and Linux kernel had nothing to do with it.

memmove and memcpy don't use a syscall, that would be very inefficient. How would a kernel fix change the behavior?