Apache OpenOffice (AOO) Bugzilla – Issue 88160
64bit: sw/source/core/doc/dbgoutsw.cxx breaks with --enable-dbgutil on amd64
Last modified: 2008-11-05 21:21:05 UTC
My --enable-debug --enable-symbols=TRUE --enable-dbgutil build on FreeBSD/amd64 7.0 failed with: ------------------------------ Making: ../../../unxfbsdx/slo/dbgoutsw.obj ccache c++ -fmessage-length=0 -c -g -O0 -fvisibility=hidden -I. -I../../../unxfbsdx/inc/doc -I../inc -I../../../inc/pch -I../../../inc -I../../../unx/inc -I../../../unxfbsdx/inc -I. -I/usr/obj/usr/ports/editors/openoffice.org-3-devel/work/DEV300_m5/solver/300/unxfbsdx/inc/stl -I/usr/obj/usr/ports/editors/openoffice.org-3-devel/work/DEV300_m5/solver/300/unxfbsdx/inc/external -I/usr/obj/usr/ports/editors/openoffice.org-3-devel/work/DEV300_m5/solver/300/unxfbsdx/inc -I/usr/obj/usr/ports/editors/openoffice.org-3-devel/work/DEV300_m5/solenv/unxfbsdx/inc -I/usr/obj/usr/ports/editors/openoffice.org-3-devel/work/DEV300_m5/solenv/inc -I/usr/obj/usr/ports/editors/openoffice.org-3-devel/work/DEV300_m5/res -I/usr/obj/usr/ports/editors/openoffice.org-3-devel/work/DEV300_m5/solver/300/unxfbsdx/inc/stl -I/usr/obj/usr/ports/editors/openoffice.org-3-devel/work/DEV300_m5/solenv/inc/Xp31 -I/usr/local/jdk1.5.0/include -I/usr/local/jdk1.5.0/include/freebsd -I/usr/local/jdk1.5.0/include/bsd -I/usr/local/jdk1.5.0/include/linux -I/usr/local/jdk1.5.0/include/native_threads/include -I/usr/local/include -I/usr/obj/usr/ports/editors/openoffice.org-3-devel/work/DEV300_m5/solver/300/unxfbsdx/inc/offuh -I. -I../../../res -I. -pipe -fvisibility-inlines-hidden -g -Wall -Wextra -Wendif-labels -Wshadow -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -fpic -DFREEBSD -DUNX -DVCL -DGCC -DC341 -DX86_64 -D_STLP_DEBUG -DCVER=C341 -DX86_64 -D_PTHREADS -D_REENTRANT -DNEW_SOLAR -D_USE_NAMESPACE=1 -DSTLPORT_VERSION=450 -DHAVE_GCC_VISIBILITY_FEATURE -D__DMAKE -DUNIX -DCPPU_ENV=gcc3 -DGXX_INCLUDE_PATH=/usr/include/c++/4.2 -DSUPD=300 -DDEBUG -DDBG_UTIL -DOSL_DEBUG_LEVEL=2 -DCUI -DSOLAR_JAVA -DDEV300=DEV300 -DACCESSIBLE_LAYOUT -DSW_DLLIMPLEMENTATION -DSHAREDLIB -D_DLL_ -fexceptions -fno-enforce-eh-specs -DEXCEPTIONS_ON -o ../../../unxfbsdx/slo/dbgoutsw.o /usr/obj/usr/ports/editors/openoffice.org-3-devel/work/DEV300_m5/sw/source/core/doc/dbgoutsw.cxx /usr/obj/usr/ports/editors/openoffice.org-3-devel/work/DEV300_m5/sw/source/core/doc/dbgoutsw.cxx: In function 'const String lcl_dbg_out(const SfxItemSet&)': /usr/obj/usr/ports/editors/openoffice.org-3-devel/work/DEV300_m5/sw/source/core/doc/dbgoutsw.cxx:299: error: cast from 'const SfxPoolItem*' to 'sal_uInt32' loses precision dmake: Error code 1, while making '../../../unxfbsdx/slo/dbgoutsw.obj' ERROR: Error 65280 occurred while making /usr/obj/usr/ports/editors/openoffice.org-3-devel/work/DEV300_m5/sw/source/core/doc Quick patch that works for me: --- sw/source/core/doc/dbgoutsw.cxx.orig 2008-04-11 03:19:13.586159454 +0200 +++ sw/source/core/doc/dbgoutsw.cxx 2008-04-11 03:48:29.485837934 +0200 @@ -296,7 +296,7 @@ if (!bFirst) aStr += String(", ", RTL_TEXTENCODING_ASCII_US); - if ((sal_uInt32)pItem != 0xffffffff) + if ((sal_uIntPtr)pItem != ~0UL) aStr += lcl_dbg_out(*pItem); else aStr += String("invalid", RTL_TEXTENCODING_ASCII_US); What can we do to make this patch portable? (How do I make portable -1? :-)
@saperski: It needs to be clarified how the bit pattern is written into the pointer in the first place. If it is written as all ones (i.e., -1) I would use reinterpret_cast< sal_IntPtr >(pItem) != -1 and if it is written as exactly eight ones (with zero or more leading zeros, depending on pointer size) I would use reinterpret_cast< sal_uIntPtr >(pItem) != 0xffffffff (and maybe it is written as some define or const, in which case I would try to use that instead of the literal value here, too).
I've had a quick look and I've found that there is a "state" of SfxPoolItem sometimes referened to as SFX_ITEM_DONTCARE (http://lxr.go-oo.org/ident?i=SFX_ITEM_DONTCARE) and checked via SfxPoolItem::IsInvalidItem: http://lxr.go-oo.org/source/util/svtools/inc/svtools/poolitem.hxx#374 Item is invalidated with void SfxItemSet::InvalidateItem( USHORT nWhich ): http://lxr.go-oo.org/source/util/svtools/source/items1/itemset.cxx#1456 This uses (SfxItemPtr *)-1 to "invalidate" the pointer. There is also a very nice void SfxItemSet::InvalidateAllItems() http://lxr.go-oo.org/source/util/svtools/source/items1/itemset.cxx#512 that just goes with plain "memset(..., -1,... )" all over. More or less all methods cast -1 to a pointer (SfxItemPtr *). Is the correct code (SfxItemPtr *)-1 if (pItem != (SfxItemPtr *)-1) { but somehow I feel that if (! pItem->IsInvalidItem()) { would be much better.
looks like !IsInvalidItem(pItem) is indeed the best fix
Hmm in DEV300_m15 it has been fixed as: if ((sal_uIntPtr)pItem != SAL_MAX_SIZE) even though better fix is: if (! pItem->IsInvalidItem()) .
duplicate to 89217 *** This issue has been marked as a duplicate of 89217 ***
close the duplicate