The trouble with this whole argument is that while the user may not care today, things like standards and defined interfaces are all about keeping things working tomorrow. Your user will surely be just as upset at something breaking tomorrow as they are today, and it's increasingly likely that such breakages will (a) occur and (b) cost more to fix, the longer you implicitly support deviations from the standards.

In this particular case, however, simply making memcpy() handle overlapping moves correctly would not break anything. Well, I suppose there's a theoretical possibility that someone is counting on the old behavior in the backwards-overlapping case, but that would be bizarre; surely this is the kind of code that should get broken, if any of it even exists.

If memcpy() had been fixed 30 years ago to do overlapping moves correctly, as it could and should have been, that would have been the end of it; we would not be having this conversation.

How hard can it be for Adobe to write standards conforming code?

The user doesn't care, but professional software developers, which I assumes Adobe's developers are, should make it a priority to follow the relevant standards.

Pretty hard. C is a minefield of undefined behavior. Integer overflow is considered undefined behavior. Which means its perfectly valid to call abort(), wipe your hard drive, then light your system on fire. Or, have the number quietly wrap around.

Oh, and its perfectly fine for me to change the behavior from one to the other, or even have a lookup table of random responses to undefined behavior. Because, like, you're not following the standard. And its so easy.

> C is a minefield of undefined behavior. Integer overflow is considered undefined behavior.

Only for signed integers. Unsigned integers are defined to wrap around.

Yea, I remember the joke about gcc #pragma once causing something like rogue to run.

For what it's worth, I agree. Every time I hear about problems that arise from programming in C, with its undefined behaviour etc., I think to myself, there must be a better way to do it. But I don't know of any way that wouldn't involve scrapping 90%+ of software we use every day.

Precisely.

It also indicates that Adobe don't run their code through valgrind, which would have picked this problem up.

Considering that flash is (a) security critical and (b) often full of security bugs, you'd think they might run valgrind over it once in a while.

Entirely Adobe's fault this one.

BTW with Firefox 4 the need for flash has virtually gone. All the popular video sites can play most of their videos using the native video support in the browser.

I was under the impression that Valgrind didn't play nice with virtual machines.

Generally no, out of the box it doesn't, things like JITs and GCs can confuse it, however it's got a bunch of flags and config options and what not to allow you to use it.