Apache OpenOffice (AOO) Bugzilla – Issue 74117
Adding runtime checks to static_int_cast
Last modified: 2017-05-20 11:31:31 UTC
This is a hacked-up enhancement to sal::static_int_cast, which employs boost::numeric_cast internally (currently, for debug builds only), to perform range checks for the cast.
Created attachment 42662 [details] Proposed patch
I'm aware that including boost headers in sal might be a bad idea, further more, this incurs a hefty increase in parse time (types.h is prolly included from _every_ c/cxx file). Comments much appreciated...
But generally, I think this or something quite similar will, like STLP_DEBUG, unearth a couple of quite serious flaws... But see this for a somewhat different approach to this problem: http://msdn.microsoft.com/library/en-us/dncode/html/secure01142004_sample.txt
We have deliberately avoided to include boost in the URE API (SDK does not provide boost in the build environment, but probably does support building with OSL_DEBUG_LEVEL>0). That problem might be solved by moving the actual boost call (and #include "boost/cast.hpp") into a non-inlined function exported from sal. [The msdn link is a 404 for me, btw.]
hrmpf. appears that msdn does not like deep links. try this: http://msdn2.microsoft.com/en-us/visualc/aa336487.aspx
Also, I am not that happy with extending static_int_cast to arbitrary arithmetic types. static_int_cast was introduced in the context of making code warning free, which often involves converting between different integral types at the edges of "different worlds" that happen to use different integral types for similar concepts "by accident." It was feared that using plain static_cast instead would make those places harder to find should one of the "different worlds" decide to change its integral types in the future. I think conversion between integral and floating point types is rarely (if ever) necessary at such edges. (And, it would make "static_int_cast" a misnomer.)
regarding boost inclusion: yes, that extra level of indirection might do, but only if we limit the cast to a finite set of specializations/overloads. And somewhat related to that problem might be the fact that static_int_cast is a bit misplaced in types.h ...
@sb: regarding integral vs. arithmetic types - yes, I understand the initial intention. maybe we should enforce this contract?
"that extra level of indirection might do, but only if we limit the cast to a finite set of specializations/overloads" Argh, yes, how unfortunate. However, "maybe we should enforce this contract?" would fit there nicely again, if we turn static_int_cast into an explicit set of specializations (and then, sal/types.h is also a logical place for it, as the set of specializations needs to be compiler dependent---think of a compiler that has additional, non-standard integral types).
@sb: sounds like a plan to me. will whip up something along this lines...
.
Retargetted, still needs some work.
set target 3.0
Retargetting due to resource constraints
cl->sb: please take over or close
Reset assigne to the default "issues@openoffice.apache.org".