Bug 28046 - NSArray bindings nint vs. nuint
Summary: NSArray bindings nint vs. nuint
Alias: None
Product: iOS
Classification: Xamarin
Component: XI runtime ()
Version: XI 8.8.0
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2015-03-15 12:17 UTC by Neal
Modified: 2015-03-16 10:19 UTC (History)
3 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Neal 2015-03-15 12:17:44 UTC

I'm trying to track down some CoreData issues and I'm looking at the NSArray we are expecting such as a count.  I'm looking at the Assembly browser for NSArray and I am seeing mixed use of nint and nuint where I think the nint's should in fact be nuint - can you please review/verify?

Thank you.

internal static NSArray FromNativeObjects (INativeObject[] items, nint count);

		[Export ("arrayWithObjects:count:"), CompilerGenerated]
		internal static NSArray FromObjects (IntPtr array, nint count);

Comment 1 Udham Singh 2015-03-16 06:28:01 UTC
I have checked this issue and observed the reported behaviour. Please refer the screencast : http://www.screencast.com/t/EPfIizGL

Environment Info : 

=== Xamarin Studio ===

Version 5.9 (build 218)
Installation UUID: ce927b2a-2c07-44c5-b186-09cfdafba6dc
	Mono 4.0.0 ((detached/565c18b)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 400000068

=== Apple Developer Tools ===

Xcode 6.2 (6776)
Build 6C131e

=== Xamarin.iOS ===

Version: (Business Edition)
Hash: 01afb49
Branch: master
Build date: 2015-03-15 01:52:46-0400

=== Build Information ===

Release ID: 509000218
Git revision: 908c39cbafdaf712059565e80591c06830fdf590
Build date: 2015-03-13 15:05:04-04
Xamarin addins: a87d89e3612e207fe3ccc142b1c2a2eb0deff730

=== Operating System ===

Mac OS X 10.9.5
Darwin Xamarin76s-Mac-mini.local 13.4.0 Darwin Kernel Version 13.4.0
    Sun Aug 17 19:50:11 PDT 2014
    root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64
Comment 2 Sebastien Pouliot 2015-03-16 10:17:29 UTC
Yes, it should have been.

There are some (mostly legacy) cases where it was decided to use `int` over `uint` in the public API. The main reasons are that `int` is normally used by .NET (and it avoid a lot of casting) and `uint` is not CLS compliant.

Note that this does not affect the use of the API unless you have more than 2^31 items (on a 32bits app). In this case you'll run out of memory before this condition can happen.
Comment 3 Neal 2015-03-16 10:19:50 UTC
Thanks Sebastian, we are trying to pin down why we're having major CoreData issues with ARM64/unified as per http://forums.xamarin.com/discussion/35802/coredata-and-arm64-unified-instability and this is one area we've seen issues with some fetches.