https://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #58 from Erich E. Hoover <erich.e.hoover(a)gmail.com> ---
(In reply to Indrek Ardel from comment #57)
(In reply to Erich E. Hoover from comment #56)
,,,
1) 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.
2) 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;
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.