On Tue, Jun 7, 2011 at 12:32 PM, Petr Mladek <[email protected]> wrote: > I havn't pushed 0001-Replace-List-for-std-vector-XclObj.patch because I am > not sure about > > --- cut --- > + inline sal_uInt16 size () const { return > static_cast<sal_uInt16>(maObjs.size()); } > --- cut --- > > If I understand it correctly, it is a replacement for > > --- cut --- > sal_uIntPtr Count() const { return nCount; } > --- cut --- > , see > http://opengrok.libreoffice.org/xref/libs-gui/tools/inc/tools/contnr.hxx#99 > > > The original object might have a bigger size. I guess that you have used > sal_uInt16 because of > > --- cut --- > sal_uInt16 XclExpObjList::Add( XclObj* pObj ) > { > - OSL_ENSURE( Count() < 0xFFFF, "XclExpObjList::Add: too much for Xcl" ); > - if ( Count() < 0xFFFF ) > + OSL_ENSURE( maObjs.size() < 0xFFFF, "XclExpObjList::Add: too much for > Xcl" ); > --- cut --- > > So, it should not go over 2bytes. Though, IMHO, it is quite dangerous to > use sal_uInt16 because it could overflow easily and if it overflows, it is > again lower than 0xFFFF. > > => I would suggest to use the sal_uIntPtr.
If the type can be changed that mean it is not part of the ABI. presumably we don't care for the exact size as long as it is reasonable big (ie > 16 bits) so, at that point what is wrong with using plain 'int' ? (I dislike using uIntPtr for things that are not even remotely related to the need to convert pointer to scalar or vice-versa,) Norbert _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
