Skip to content

Add explicit and implicit cast operators for unsigned integer types - #945

Merged
jonpryor merged 1 commit into
dotnet:masterfrom
grendello:bug59193
Oct 18, 2017
Merged

Add explicit and implicit cast operators for unsigned integer types#945
jonpryor merged 1 commit into
dotnet:masterfrom
grendello:bug59193

Conversation

@grendello

Copy link
Copy Markdown
Contributor

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.

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.
@jonpryor
jonpryor merged commit 7f8f50c into dotnet:master Oct 18, 2017
@grendello
grendello deleted the bug59193 branch October 18, 2017 20:36
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.
@github-actions github-actions Bot locked and limited conversation to collaborators Feb 4, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants