https://bugs.documentfoundation.org/show_bug.cgi?id=112928
Julien Nabet <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected],
| |[email protected]
--- Comment #26 from Julien Nabet <[email protected]> ---
Stephan/Mike: last V Stuart Foote's bt indicates the pb is:
00e3f78c 002d9eed kernel32!CreateFileW+0x35f
00e3f7c0 013844c4 sal3!osl_openFile(struct _rtl_uString * strPath = 0x02e2b4b0,
void ** pHandle = 0x02e8c914, unsigned long uFlags = 1)+0x7d
[c:\cygwin64\home\buildslave\source\libo-core\sal\osl\w32\file.cxx @ 737]
thought you might be interested in this bugtracker.
Here's the line:
720 HANDLE hFile = CreateFileW(
721 o3tl::toW(rtl_uString_getStr(strSysPath)),
722 dwAccess, dwShare, nullptr, dwCreation, 0, nullptr);
See https://opengrok.libreoffice.org/xref/core/sal/osl/w32/file.cxx#720
I tried to unwind this:
"rtl_uString_getStr" returns "sal_Unicode *"
see https://opengrok.libreoffice.org/xref/core/include/rtl/ustring.h#1414
then "sal_Unicode" is "wchar_t" for SAL_W32
138 #elif defined(SAL_W32)
139 typedef wchar_t sal_Unicode;
see https://opengrok.libreoffice.org/xref/core/include/sal/types.h#137
o3tl::toW takes for input char16_t * and returns wchar_t *
https://opengrok.libreoffice.org/xref/core/include/o3tl/char16_t2wchar_t.hxx#15
It seems we call o3tl::toW with an arg which is already wchar_t, could the
implicit conversion to char16_t be the culprit?
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
