I'm sorry, but memcpy has never crashed simply due to overlapping
regions and there is no evidence for this. We've been using it for
nearly 20 years now and never had a crash when the src and dst memory
regions are within the bounds of an image.
You are taking language meant to cover them for "we do not guarantee
that overlapping memory copies won't make a mess of the data you are
copying" to somehow infer that it can read or write outside the
indicated bounds. At worst the pixels will be jumbled and that would
not cause any crashes, it would simply look wrong on the screen. The
thread that Sergey pointed to even went so far as to have developers
claim that the exact specific way that it jumbles the data it is copying
is considered part of the contract even though the behavior is specified
as undefined. Crashing is completely outside the scope of its undefined
claim.
The only viable reason for switching to memmove is to either silence the
tool that reported the issue or to fix the data ordering issue. There
are other ways to silence the tool without making one of our blits have
behavior that doesn't match other similar blits, and if we are going to
fix the data ordering issue we should do it for all blits...
...jim
On 5/28/2015 12:58 AM, Andrew Haley wrote:
On 28/05/15 01:06, Jim Graham wrote:
Where do you see evidence that it can crash?
It's what the language specification says. Undefined behaviour is
unconstrained: it can do anything. Demons might fly out of your nose.
We have seen with GCC that apparently "harmless" code (a read just
beyond the end of an array) can, for example, result in an infinite
loop. In this case, it is quite possible that GCC could infer that
the two memory regions accessed by memcpy do not overlap.
Andrew.
