Add explicit and implicit cast operators for unsigned integer types - #945
Merged
Conversation
Context: https://bugzilla.xamarin.com/show_bug.cgi?id=59193 Java does not include types to represent unsigned integers. This poses a problem when either porting code from Java to managed languages or when attempting to cast integer values between the Java and the managed land. The issue described in the above bug could be fixed by adding appropriate implicit and explicit operators to Java.Lang.Object in Xamarin.Android but that would allow for behavior which may have adverse effects without any external signs immediately visible to the developer. Consider a situation when a minimum signed 32-bit integer value returned by Java code is cast to the managed `uint` type - we end up with the same value but with different sign and no indication given that such a thing happened. We could up-cast the value to long but that changes the type of the result and is not advisable, especially with implicit conversions. Also, even if the value was up-cast to a type with a larger value range this would have to stop with the 64-bit integers since they can't be up-cast to any other primitive integer type. Any casts between signed and unsigned integer types should be a conscious and explicit action, thus the double cast `(ulong)(long)value` is considered the correct behavior. For those reasons we decided that the best action to to take is to actively prevent direct casts from/to a managed unsigned integer type to/from a signed Java integer type. This is implemented by way of adding a number of explicit and implicit conversion operators to XA's Java.Lang.Object implementation that are marked "obsolete" and being erroneous. This is done this way so that the code attempting to perform such conversions won't build because the compiler, seeing the attribute, will signal an error and abort the build.
Redth
pushed a commit
to Redth/xamarin-android
that referenced
this pull request
Oct 30, 2017
) Context: https://bugzilla.xamarin.com/show_bug.cgi?id=59193 Java does not include types to represent unsigned integers. This poses a problem when either porting code from Java to managed languages or when attempting to cast integer values between the Java and the managed land. The issue described in the above bug could be fixed by adding appropriate implicit and explicit operators to Java.Lang.Object in Xamarin.Android but that would allow for behavior which may have adverse effects without any external signs immediately visible to the developer. Consider a situation when a minimum signed 32-bit integer value returned by Java code is cast to the managed `uint` type - we end up with the same value but with different sign and no indication given that such a thing happened. We could up-cast the value to long but that changes the type of the result and is not advisable, especially with implicit conversions. Also, even if the value was up-cast to a type with a larger value range this would have to stop with the 64-bit integers since they can't be up-cast to any other primitive integer type. Any casts between signed and unsigned integer types should be a conscious and explicit action, thus the double cast `(ulong)(long)value` is considered the correct behavior. For those reasons we decided that the best action to to take is to actively prevent direct casts from/to a managed unsigned integer type to/from a signed Java integer type. This is implemented by way of adding a number of explicit and implicit conversion operators to XA's Java.Lang.Object implementation that are marked "obsolete" and being erroneous. This is done this way so that the code attempting to perform such conversions won't build because the compiler, seeing the attribute, will signal an error and abort the build.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context: https://bugzilla.xamarin.com/show_bug.cgi?id=59193
Java does not include types to represent unsigned integers. This poses a problem
when either porting code from Java to managed languages or when attempting to
cast integer values between the Java and the managed land.
The issue described in the above bug could be fixed by adding appropriate
implicit and explicit operators to Java.Lang.Object in Xamarin.Android but that
would allow for behavior which may have adverse effects without any external
signs immediately visible to the developer.
Consider a situation when a minimum signed 32-bit integer value returned by Java
code is cast to the managed
uinttype - we end up with the same value but withdifferent sign and no indication given that such a thing happened. We could
up-cast the value to long but that changes the type of the result and is not
advisable, especially with implicit conversions. Also, even if the value was
up-cast to a type with a larger value range this would have to stop with the
64-bit integers since they can't be up-cast to any other primitive integer type.
Any casts between signed and unsigned integer types should be a conscious and
explicit action, thus the double cast
(ulong)(long)valueis considered thecorrect behavior.
For those reasons we decided that the best action to to take is to actively
prevent direct casts from/to a managed unsigned integer type to/from a signed
Java integer type. This is implemented by way of adding a number of explicit and
implicit conversion operators to XA's Java.Lang.Object implementation that are
marked "obsolete" and being erroneous. This is done this way so that the code
attempting to perform such conversions won't build because the compiler, seeing
the attribute, will signal an error and abort the build.