https://bugs.freedesktop.org/show_bug.cgi?id=64394
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |UNCONFIRMED Ever confirmed|1 |0 --- Comment #7 from [email protected] --- About the >>= operator of the Any class, using its overloaded method inline sal_Bool SAL_CALL operator >>= ( const Any & rAny, sal_Int32 & value ) SAL_THROW( () ) the user's requirement is: "please, convert to sal_Int32 as far as this is possible"; so the user is not asking to retrieve the enum value as an enum type. It seems that today the >>= operator implementation is definitely consistent about the type dimension, i.e. a type is never converted to a smaller sized type and, in this case, the operator returns false. This is a good pattern and, for this overload, the reasonable input, as now, are the following typelib_TypeClass_* types: BYTE, SHORT, UNSIGNED_SHORT, LONG, UNSIGNED_LONG. So, the weakeness is already accepted about the signed/unsigned known issues. Now, what about typelib_TypeClass_ENUM? What is its size? For sure it is less than or equal to the bit depth of the processor, or, better, the bit depth of the binary. So, nowadays at least inline sal_Bool SAL_CALL operator >>= ( const Any & rAny, sal_Int64 & value ) SAL_THROW( () ) and inline sal_Bool SAL_CALL operator >>= ( const Any & rAny, sal_uInt64 & value ) SAL_THROW( () ) could safely handle typelib_TypeClass_ENUM. And, using some size check (right now I cannot say at compile-time or run-time), sal_Int32/sal_uInt32 and whatever destination integer/float/double type could too. The idea is: as far as possible/reasonable, better doing validity checks, in the callee code rather than in the caller code on the returned value. Otherwise, as it is today, the user's code is interleaved not only by the check about the operator return value (true/false), but also, if false, by the check if it is a typelib_TypeClass_ENUM to then make the conversion by his/her-self. But, I must admit, the word "reasonable" is always opened to personal opinions, in turn reasonable and, for sure, interesting. Thanks for time. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
