HI Stephan,
On Wed, 2012-02-29 at 15:25 +0100, Stephan Bergmann wrote:
On 02/29/2012 12:13 PM, Lionel Elie Mamane wrote:
Background: we have in sc/source/filter/inc/ftools.hxx supposedly
"safe" casts that are (according to the Doxygen documentation)
supposed to be safer than just static_cast. As fdo#39589 uncovered,
they are actually so buggy as to be *less* safe.
Are those "saturating" ulimit_cast a good thing, anyway? Looks like
they are only used in a handful of sc/source/filter/excel/ files.
That's my take also. Their uses are very limited, and there are
alternatives we could use (SafeInt, boost::numeric_cast) if we really
have to use one.
Picking the first occurrence at random,
return ulimit_cast< sal_uInt16 >( nValueCount, EXC_CHDATAFORMAT_MAXPOINTCOUNT );
from XclExpChSourceLink::ConvertDataSequence (xechart.cxx), where
nValueCount is a sal_uInt32 quantity -- is it OK to silently truncate
this quantity here, or does it rather indicate a conversion failure that
should be reported to the user?
I personally think it's perfectly okay to just truncate the value in
this particular case.
Kohei
--
Kohei Yoshida, LibreOffice hacker, Calc
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.