https://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #57 from Indrek Ardel eniw@ardel.eu --- (In reply to Erich E. Hoover from comment #56)
I'm sorry I have not been very responsive lately, things have been very busy.
- it looks like the original allocated buffer was two bytes too short
because there should be added room for two WCHARs (as opposed to two chars). this is probably the real source of the problem. 2) you are no longer copying the NULL WCHAR into the nt_full_target buffer, while not strictly necessary I've found that it is _much_ harder to debug strange issues when you do not NULL-terminate these strings.
The other patch is certainly correct, my apologies for missing that previously.
1) I do not quite follow, why two WCHAR-s? Isn't |A| + |B| + 1 WCHAR-s sufficient or are talking of different buffers?
2) This is valid criticism, you are correct that an extra WCHAR is now no longer copied from nt_target. However in that case it looks like nt_target is the buffer that is missing a NULL WCHAR as it should have been copied properly into nt_full_target by memcpy and wcslen should have subsequently recognized it, which in my case was not happening.
Having to manually account for an implicit NULL WCHAR in UNICODE_STRING-s when copying buffers directly seems very error prone if someone breaks that convention elsewhere. Perhaps there exists a utility function already in the project that could copy one UNICODE_STRING at the end of the other while taking care of the implicit NULL WCHAR regardless of whether the source string has one?