https://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #58 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Indrek Ardel from comment #57)
(In reply to Erich E. Hoover from comment #56) ,,,
- I do not quite follow, why two WCHAR-s? Isn't |A| + |B| + 1 WCHAR-s
sufficient or are talking of different buffers?
Ignore me, for some reason I got my wires crossed and thought that this was one of the places that combines two separate buffers in order to construct a [MountPoint|SymbolicLink]ReparseBuffer.
- This is valid criticism, you are correct that an extra WCHAR is now no
longer copied from nt_target.
I would recommend NULL-terminating the string manually then, as not all of the wide character functions deal with non-NULL-terminated strings very well. In particular, I've found that it can be challenging to FIXME debugging with the strings if you don't NULL-terminate them.
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.
That should not be happening, Windows requires that the strings for both Symbolic Links and Junction Points be NULL-terminated (note that this is not necessarily true of all reparse tags, since they all have their own quirks). It's been a while since I played with this, but I definitely remember that if you tried to "cheat" and not have a NULL character that it would reject the [MountPoint|SymbolicLink]ReparseBuffer. Do you know how the reparse point is being created? Maybe I have a mistake somewhere and it's creating and passing a non-NULL-terminated string to one of the lower level functions.
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.
Yeah, I have also struggled with this. I haven't looked into it too deeply, but I suspect that this is a "we need to be bug compatible" kind of thing.
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?
I don't think that we have something that already does this, what I've seen wine do most places is something like (with the appropriate "len" for the WCHAR): buffer[len] = 0;