Re: [PATCH] ntdll: Pad the FILE_*_DIRECTORY_INFORMATION with zero bytes

[Alexandre Julliard]

Martin Storsjo <martin(a)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.

-- 
Alexandre Julliard
julliard(a)winehq.org

[PATCH] ntdll: Pad the FILE_*_DIRECTORY_INFORMATION with zero bytes

[Martin Storsjö]

On Tue, 13 May 2014, Alexandre Julliard wrote:
> Martin Storsjo <martin(a)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