summaryrefslogtreecommitdiffstats
path: root/newlib/libc/unix
diff options
context:
space:
mode:
authorCorinna Vinschen <corinna@vinschen.de>2017-06-06 18:27:47 +0200
committerCorinna Vinschen <corinna@vinschen.de>2017-06-06 18:27:47 +0200
commitc0d7d3e1a2fa96db15613cbd68a68c96966bc402 (patch)
tree98a427d58e53cf2c9f404971bc39b7f7a367fb4e /newlib/libc/unix
parent780503f6acf9e0795c3b7a686a2815620098f8da (diff)
downloadcygnal-c0d7d3e1a2fa96db15613cbd68a68c96966bc402.tar.gz
cygnal-c0d7d3e1a2fa96db15613cbd68a68c96966bc402.tar.bz2
cygnal-c0d7d3e1a2fa96db15613cbd68a68c96966bc402.zip
cygwin wcsxfrm: byte swap result ourselves
Workaround a bug (or undocumented behaviour) in LCMapStringW: It's documented(*) that the cchDest parameter is a byte count with LCMAP_SORTKEY, but a character count otherwise. But the docs don't state what happens if you combine LCMAP_SORTKEY with LCMAP_BYTEREV. Tests indicate that LCMAP_SORTKEY treats cchDest as byte count, but then LCMAP_BYTEREV treats it as char count in the same call. So the latter swaps twice as much bytes in the destination buffer than the byte count it returns, which potentially results in writing past the end of the given output buffer. Solution: Don't specify LCMAP_BYTEREV in the LCMapStringW(LCMAP_SORTKEY) call, rather byte swap afterwards. (*) https://msdn.microsoft.com/en-us/library/windows/desktop/dd318702(v=vs.85).aspx Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Diffstat (limited to 'newlib/libc/unix')
0 files changed, 0 insertions, 0 deletions