I've asked around internally and the overwhelming
consensus is that memcpy is not dangerous in
the overlapping case. Our security/vulnerability
expert does not see a problem - as long the
pointers are valid of course.
The long-ago author of the memcpy man page
surely meant that the end resulting b
On 28/05/15 21:33, Jim Graham wrote:
> 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.
Or to remove the UB. Your opinion that UB is constrained is wrong in
principle and dangerous in practice. It is extr
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
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 t
Where do you see evidence that it can crash?
...jim
On 5/27/2015 3:54 AM, Andrew Haley wrote:
On 05/27/2015 11:36 AM, Sergey Bylokhov wrote:
On 26.05.15 21:27, Jim Graham wrote:
Undefined doesn't mean "may crash" in this case, it means that the
contents of memory may not match
I see no evidence that it can crash. Again, undefined does not mean
"can crash". Someone joked on that thread that they should probably
make memcpy crash on overlapping memory moves in a future release, but I
don't see any evidence that anyone took them seriously. The entire
thread is more a
On 05/27/2015 11:36 AM, Sergey Bylokhov wrote:
> On 26.05.15 21:27, Jim Graham wrote:
>> Undefined doesn't mean "may crash" in this case, it means that the
>> contents of memory may not match what you would expect if the regions
>> overlap because it is just a dump copy loop that does not do any
On 26.05.15 21:27, Jim Graham wrote:
Undefined doesn't mean "may crash" in this case, it means that the
contents of memory may not match what you would expect if the regions
overlap because it is just a dump copy loop that does not do any
aliasing checks.
Since it is undefined it can crash, but
Compilers have also gotten really really good at recognizing memory copy
loops and applying the same optimizations automatically depending on the
optimization level.
I'd really prefer to just leave this code alone and maybe find a way to
tag the line to silence the warnings from the tool. If
Hi Jim,
> If there is no way to silence the tool, then I'd recommend hard-coding our
> own "dumb copy loop" instead so that the behavior continues to match what
> memcpy should have been doing.
Isn't performance/throughput a concern for this case?
Mamcpy is usually highly tuned with hand-optimize
Undefined doesn't mean "may crash" in this case, it means that the
contents of memory may not match what you would expect if the regions
overlap because it is just a dump copy loop that does not do any
aliasing checks.
Is there a way to silence the warning? In this particular case we are
tot
On 26.05.15 13:43, Jim Graham wrote:
What crash in memcpy?
Simply because behavior of this function is undefined if the two arrays
"to" and "from" overlap. Plus this clears an output for the tools like
valgrind and some other issues can be found easily.
The issue you pointed to is about deali
What crash in memcpy? The issue you pointed to is about dealing with
overlapping memory. memcpy does not crash on overlapping memory copies,
it just duplicates data oddly in a way that most uses probably don't want.
Also, the fix you gave only fixed the problem for the horizontal
direction,
Hi, Jim.
Actually there is a difference in support: it works but result is a
little bit wrong, and it does not work and crashes. This fix is not a
general solution for the incorrect result of the blit+aliasing, but for
the possible crash of memcpy especially after some improvements like in
gli
I don't recall if we ever promised that this case would work without
aliasing issues. I know that we went out of our way in the copyArea
method to prevent the aliasing issue, doing the blits piecemeal so that
they don't interfere with each other. Further, while it may be easy
enough to just c
Hello.
Please review the fix forjdk9.
I found this issue during code review of another task, related to
performance.
The sample code below will call the IsomorphicCopy method which call
memcpy on the overlapping memory(this is the simplest example)
BufferedImage img = new BufferedImage
16 matches
Mail list logo
