On Sunday, February 10, 2013 07:37 CET, Richard Frith-Macdonald <[email protected]> wrote: > > On 9 Feb 2013, at 18:11, Sebastian Reitenbach wrote: > > > Hi, > > > > when I see something like this for example in ProjectCenter: > > > > - (NSInteger)numberOfRowsInTableView: (NSTableView *)aTableView > > { > > return [docTypesItems count]; > > } > > > > where docTypesItems is a NSMutableArray. I see many of the GUI elements > > use NSInteger. But for example NSArray, or NSDictionary count return > > NSUInteger. > > > > When I see above statement, how is best way to proceed to not for > > example return a too large NSUInteger, which would convert into > > a negative NSInteger? > > > > Since most of the time I see contents of tables, browsers and whatnot > > stored in NSArrays or NSDictionaries, nearly everywhere I came across > > I see this potential trouble with the signed vs. unsigned > > discrepancies when setting it up in the GUI. > > > > Also often I see some of those results then compared, actually comparing > > a NSUInteger against a NSInteger. When one is too large, or the other > > negative, funny things may happen. > > > > Is there some best practices, how to handle that? Or is there something in > > the runtime, I am not aware of, that takes care about it? > > Well, there are two good things: > > 1. A direct equality test against NSNotFound will work for both NSInteger and > NSUInteger, so that's OK.
yeah, that is also fine with me ;) > > 2. in most contexts in the GUI, it's safe to assume that no data structure > will contain more than two billion (2^31) elements ... so you don't have to > worry about things like array counts returning values which would turn > negative when converted. Generally, if you had anything even remotely close > to that number of elements in a GUI data structure, your app would be > effectively dead anyway. Yeah, I assumed that, in normal cases it should not matter. But what if someone accidently or maliciously creates around 2^31 files in a directory, and then the file browser chokes on that? > > Anywhere that those two cases don't apply, you need to check the value of > NSUInteger before you treat it as an NSInteger. > So, while it's good to review these cases, and important to treat them with > care, it's usually fine to simply cast the unsigned value to be a signed one. > So, when I assume to be surrounded by malicious people, I probably should always check, regardless where the input comes from, otherwise, assuming friendly people, I probably can assume to be safe most of the times. thanks, Sebastian _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
