Re: bug: unsigned short, NSArrayController, NSTableView?
Re: bug: unsigned short, NSArrayController, NSTableView?
- Subject: Re: bug: unsigned short, NSArrayController, NSTableView?
- From: Steve Christensen <email@hidden>
- Date: Sun, 27 May 2007 16:14:18 -0700
On May 27, 2007, at 1:11 PM, Todd Heberlein wrote:
I don't know if this is a defined behavior or a bug, so I thought I
would toss it out here before submitting it as a bug. The punch-
line is that an NSTableView column that is fed data via an
NSArrayController does not display large values for unsigned shorts
correctly.
I have an NSObject subclass that has an unsigned short to represent
a 16-bit TCP port. The accessors also use an unsigned short for
setting/retrieving the value.
The objects are placed in an NSMutableArray which is tracked by an
NSArrayController. An NSTableView's columns bind to the
NSArrayController for their data.
THE PROBLEM: When the port value is a large number (e.g., when the
highest order bit is set), the table view shows a negative number
instead of a large positive number.
The work around was easy enough: just make the port a 32-bit number.
Is this the defined behavior (i.e., not supporting unsigned
shorts), and is therefore my mistake?
Or is this a bug that should be reported?
I would expect the compiler to honor the sign of a number and, for
example, zero-extend an unsigned short to before stuffing into a
larger data type such as long or int. Is it possible that you're
inadvertently casting the port number before passing it along as a
table value, e.g.,
int displayValue = (int) [somePortObject portNumber];
so the compiler would treat the port number as a signed short and
then just sign-extend the value?
steve
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden