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

Reply via email to