I may be overdoing it a bit here, but personally I don't agree with Torvald's p.o.v. at all. While user experience is obviously important, allowing mistakes like this to go unchallenged by simply providing a work-around just encourages people to write broken software. Specs exist for a reason. Ignoring them is not it.
I do this in my own software as well. If a user files a bug because input X fails to process as expected -- and it turns out his/her input does not meet the spec -- I do not supply a fix. Even if his/her supplied input is widely used in 'the wild'. While this alienates a considerable user base, I refuse to be part of the problem.
Myself I would go for a compromise. Flash's behaviour (using memcpy when then mean memmove) is definitely faulty, and it's not an obscure C undefined behavior either, I'm sure any C tutorial worth mentioning has "if you want to copy overlapping regions of memory, use memmove" somewhere in the middle. I'd just fill a bug on adobe's bugtracker, tell them "we'll keep the current for X months, but then we'll switch to a new implementation, so if it still breaks it's up to you". With X being a reasonable enough lapse of time.
By the way, if flash was open source it would probably be a one line patch to fix the issue, but it's not, and I wouldn't blame the fedora/glibc devs for that. Breaking things because "you can" is no good policy, but it doesn't mean you have to be backward compatible for ever, that's what being realistic is about.
I can see the moral hazard side of things; but Linus does have a point.
There has to be great benefit from changing the implementation of memcpy for it to be worth it. And broken flash is an obvious negative. And across the said thread, there is argument that the new implementation might not be the best as well. So, with two negatives and no obvious positives why do it at all?
If early web browsers has stuck to the spec and rejected all "bad" inputs, then web probably would have been a better place today. Sometimes the user's interests are in the future not in the now.
Of course. If the supplier of their input is a third party, I will even go so far as to file the appropriate bug reports with said third party for them.
Scoped properly, he's entirely correct. The user doesn't care about standards. The user cares that STUFF WORKS.
Standards serve a purpose - but standards are guidelines.
Adobe & Redhat had no contractual obligation I assume, so really it's up to either of them to fix the problem - and in fighthing about who did what wrong is pointless if a couple lines of code ora few hours of work are all it will take to make things work.
In this particular situation, the standards were not helping get things up and running, right?
Are you referring to POSIX? Because if so, you should know that it is a shining example of a worthless standard and that most unix programs rely on unspecified behavior far more than this easy-to-make flash bug.
