To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=70166
User mmeeks changed the following:
What |Old value |New value
================================================================================
CC|'' |'mhu'
--------------------------------------------------------------------------------
------- Additional comments from [EMAIL PROTECTED] Fri Oct 6 13:58:17 -0700
2006 -------
So - another curious issue - digging into why we get the strange IBM
textencodings I got stumped, an (accurate) trace for one is:
#0 Impl_getTextEncodingData (nEncoding=6) at
/data/OpenOffice/ood680-m4/sal/textenc/textenc.cxx:244
#1 0xb744a749 in rtl_createTextToUnicodeConverter () from ./libuno_sal.so.3
#2 0xb7439d27 in rtl_string2UString () from ./libuno_sal.so.3
#3 0xb77c84f4 in String (this=0x8679b28, pByteStr=0xb337b740 "symbol",
eTextEncoding=6, nCvtFlags=819) at ./strucvt.cxx:101
#4 0xb324336a in SwViewOption (this=0x8679b28) at
/data/OpenOffice/ood680-m4/sw/source/ui/config/viewopt.cxx:448
The code is:
SwViewOption::SwViewOption() :
sSymbolFont( RTL_CONSTASCII_STRINGPARAM( "symbol" ) ),
nZoom( 100 ),
where sSymbolFont is a 'String':
UniString( const sal_Char* pByteStr, xub_StrLen nLen,
rtl_TextEncoding eTextEncoding,
sal_uInt32 nCvtFlags = BYTESTRING_TO_UNISTRING_CVTFLAGS );
So - it looks like we should get an error (right?) ;-> some more head
scratching, no warning on compilation, poking at the assembler:
addl $_GLOBAL_OFFSET_TABLE_, %ebx
pushl $819
pushl $6
leal 20(%esi), %edi
leal [EMAIL PROTECTED](%ebx), %eax
pushl %eax
pushl %esi
call String::String(char const*, unsigned short, unsigned long)@PLT
We do indeed pass 6 - and we call the method with that signature;
Then you re-read the UniString constructor signatures and slap the forehead;
we're calling:
UniString( const sal_Char* pByteStr,
rtl_TextEncoding eTextEncoding,
sal_uInt32 nCvtFlags = BYTESTRING_TO_UNISTRING_CVTFLAGS );
instead - but the 'eTextEncoding' is swallowing the length ;-) - doh [!]
Now - admittedly this line comes from a patch of ours ;-) but there are plenty
of other silly examples where this is not so:
SdrLayerAdmin::SdrLayerAdmin(SdrLayerAdmin* pNewParent):
aLayer(1024,16,16),
aLSets(1024,16,16),
pModel(NULL)
{
sal_Char aTextControls[] = "Controls";
aControlLayerName = String(aTextControls, sizeof(aTextControls-1));
pParent=pNewParent;
}
void SdrFormatter::TakeUnitStr(MapUnit eUnit, XubString& rStr)
{
switch(eUnit)
{
// Metrisch
case MAP_100TH_MM :
{
sal_Char aText[] = "/100mm";
rStr = UniString(aText, sizeof(aText-1));
...
etc. etc.
So - on 1 hand good news, we don't -really- use that many text encodings ;-)
On the other hand: bad news, there are most likely a large number of cockups in
the code here [ isn't C++ polymorphism sexy ;-]
I'd like to break the UniString constructor set to remove the ambiguity; the
same problem exists for ByteString [FWIW], where (perhaps) it causes more
damage. I -suspect- that removing the plain:
ByteString( const sal_Unicode* pUniStr,
rtl_TextEncoding eTextEncoding,
sal_uInt32 nCvtFlags = UNISTRING_TO_BYTESTRING_CVTFLAGS );
constructor without the length is what we want to do (?)
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
