From: Kenneth J.Davis (firstname.lastname@example.org)
Date: Sat May 18 2002 - 05:42:30 EDT
I was tracing through the Windows code (as every menu selection causes an
assert popup in debug mode) and int UT_UCS4_mbtowc::mbtowc (UT_UCS4Char & wc, char mb)
as called from UT_UCS4Char * UT_UCS4_strcpy_char(UT_UCS4Char * dest, const char * src)
converts the char * to a big endian coded UT_UCS4Char.
UT_uint32 ap_sb_Field_PageInfo::getDesiredWidth(void) calls the above strcpy
function and passes the result to pG->measureString(bufUCS,0,len,charWidths);
where pG is a GR_Win32Graphics. Which in turn seems to think the bufUCS is a
16 bit (well there are some masks and shifts that appear only valid from 0x0 to 0xFFFF)
and in native endian format. The assertions appear to be caused by a value
being initialized to an invalid value as a result of the big endianness. While
I have some changes that are not in cvs, I do not think any of them should
effect this. My question is, should the above call to UT_UCS4_strcpy_char() be
converting the char * to an array of UT_UCS4Char(s) that are in big endian byte
order [which as far as I can tell is how the peer libiconv call is written to
perform the given conversion] or native byte order?
or am I the only one with this problem?
This archive was generated by hypermail 2.1.4 : Sat May 18 2002 - 07:14:15 EDT