On Wed, 3 Jul 2024 13:25:27 GMT, Julian Waters <jwat...@openjdk.org> wrote:
>> src/java.desktop/windows/native/libawt/windows/awt_Component.cpp line 3368: >> >>> 3366: BYTE tmpState[256]; >>> 3367: WCHAR wc[2]; >>> 3368: memmove(tmpState, kstate, sizeof(kstate)); >> >> Using `memcpy` could be more performant, we know for sure that `tmpState` >> and `kstate` do not overlap. > > I can't quite comment on that since I don't really know what the purpose of > the memmove is. What does @prrace think? Both `memcpy` and `memmove` do the same thing, namely each function copies bytes from one location into another location. The difference between these two functions is in whether buffers are allowed to overlap or not: * [`memcpy`](https://en.cppreference.com/w/c/string/byte/memcpy): <q cite="https://en.cppreference.com/w/c/string/byte/memcpy";>If the objects overlap […], the behavior is undefined.</q><br><q cite="https://en.cppreference.com/w/c/string/byte/memcpy#Notes";><em>`memcpy` is the fastest library routine for memory-to-memory copy.</em> It is usually more efficient than `strcpy`, which must scan the data it copies or `memmove`, which must take precautions to handle overlapping inputs.</q> * [`memmove`](https://en.cppreference.com/w/c/string/byte/memmove): <q cite="https://en.cppreference.com/w/c/string/byte/memmove";>The objects may overlap: copying takes place as if the characters were copied to a temporary character array and then the characters were copied from the array to `dest`.</q> > we know for sure that `tmpState` and `kstate` do not overlap. For this reason, `memcpy` is safe to use, and it is more efficient than `memmove`. To be clear, I'm not proposing to incorporate this change under this bug. I just pointed out a possible optimisation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19798#discussion_r1665654705
