Martin Storsjo martin@martin.st writes:
Instead of memcpying in whatever uninitialized data there was at the end of long_nameW, memset the tail of the struct to zero instead.
This fixes running cl.exe from MSVC 2013 with native msvcr120/msvcp120, fixing bug 35335.
MSVC 2013 (or msvcr120?) seems to use NtQueryDirectoryFile to iterate through the headers in directories in the include path, and prior to this change, the file names found during iteration could get a suffix consisting of an uninitialized WCHAR.
That doesn't make much sense, given that there may not be space for a final null, and that your patch doesn't clear the right location anyway. It looks like more investigation is needed.
On Tue, 13 May 2014, Alexandre Julliard wrote:
Martin Storsjo martin@martin.st writes:
Instead of memcpying in whatever uninitialized data there was at the end of long_nameW, memset the tail of the struct to zero instead.
This fixes running cl.exe from MSVC 2013 with native msvcr120/msvcp120, fixing bug 35335.
MSVC 2013 (or msvcr120?) seems to use NtQueryDirectoryFile to iterate through the headers in directories in the include path, and prior to this change, the file names found during iteration could get a suffix consisting of an uninitialized WCHAR.
That doesn't make much sense, given that there may not be space for a final null,
Hmm, that's true
and that your patch doesn't clear the right location anyway.
Oh crap, thanks for noticing
It looks like more investigation is needed.
Indeed, I'll try to dig around further
// Martin
-
Alexandre Julliard -
Martin Storsjö