Greetings--

In the process of fixing the Python test suite on Cygwin I ran across
one test that was consistently causing segfaults later on, not
directly local to that test.  The test involves wcsxfrm so that's
where I focused my attention.

The attached test demonstrates the bug.  Given an output buffer of N
wide characters, wcsxfrm will cause bytes beyond the destination size
to be reversed. I believe it might actually be a bug in the underlying
LCMapStringW workhorse (this is on Windows 10; have not tested other
versions).

According to its docs [1], the cchDest argument (size of the
destination buffer) is treated as a *byte* count when using
LCMAP_SORTKEY.  However, for the purposes of applying the
LCMAP_BYTEREV transformation it seems to be treating the output size
(in bytes) as character count.  So in the example I give, where the
output sort key is 7 bytes (including the null terminator), it swaps
*14* bytes--the bytes including the sort key as well as the next 7
adjacent bytes.  This is obviously a problem if the destination buffer
is allocated out of some larger memory pool.

This definitely has to be a bug, right?  Or at least very poorly
documented on MS's part.  A workaround would either be to not use
LCMAP_BYTEREV and just swap the bytes manually, or in a second call to
LCMapStringW with LCMAP_BYTEREV and the correct character count...

Thanks,
Erik


[1] https://msdn.microsoft.com/en-us/library/windows/desktop/dd318700(v=vs.85).aspx