https://bugs.freedesktop.org/show_bug.cgi?id=64394
Stephan Bergmann <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |NOTABUG --- Comment #8 from Stephan Bergmann <[email protected]> --- (In reply to renatomauro from comment #7) > 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. For historic reasons, Any::operator >>= for numeric types (and for numeric types only) employs some specific conversions that could be characterized as "widening modulo signedness." Whether or not this would be considered reasonable is somewhat irrelevant, given how much (internal and external) code has been written against that specific behaviour over time---it's just the way it is and practically impossible to change anyway. > 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 See <http://www.openoffice.org/udk/common/man/typesystem.html> for what an enum's members are. But the important thing is that an enum type is not a numeric type, as far as UNO is concerned, and conversion from the (numeric) value of an enum type's member to a numeric type is never considered by Any::operator >>=, for better or worse. (Just like it never considers conversion from boolean values, or from values of a struct type with a single numeric member field, or...) > 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. That is not necessarily a good idea. These are not "validity checks" but changes of semantics. > 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. Code that legitimately wants to extract from an any an enum value as an integer value is probably very rare. I'm closing this as NOTABUG. If you still see need for discussion, please move it to the mailing list, which is a better place for discussions like this. -- 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
