Hi Stephan,
Stephan Bergmann wrote:
In sal/types.h, sal_Unicode is a typedef for wchar_t if SAL_W32 is
defined, and for sal_uInt16 otherwise. What shall be achieved by this
is that sal_Unicode is an unsigned integral 16 bit type on all
platforms. I am now wondering why the special case for SAL_W32 is
necessary:
The way we use the MS Compiler on Windows, wchar_t there is a typedef
for unisgned short, the same type that sal_uInt16 is a typedef for.
Also, SAL_W32 can be defined for other platforms than MS Compiler on
Windows, for example it is also defined for the mingw port. However, on
that platform wchar_t is not compatible with unsigned short (it seems;
also see issue 53572).
So, since the way sal_Unicode is declared in sal/types.h probably needs
to be fixed anyway (see mingw problem), I would propose to fix it so
that sal_Unicode is a typedef for sal_uInt16 on all platforms, unless
someone knows a reason why it should be different for MS Compiler on
Windows.
Would the MS Visual Studio debugger display OOo unicode strings out of
the box when we would use a data type other then wchar_t? I don't think
so. That's why I would stick with the special wchar_t typedef on Windows.
Kind regards,
Tino
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
