[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSInteger vs. NSUInteger

From: Ivan Vučica
Subject: Re: NSInteger vs. NSUInteger
Date: Sun, 10 Feb 2013 12:39:27 +0100

On 10. 2. 2013., at 12:23, "Sebastian Reitenbach" <address@hidden> wrote:

> On Sunday, February 10, 2013 07:37 CET, Richard Frith-Macdonald 
> <address@hidden> wrote: 
>> 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?

Filesystem will choke far, far, FAR before the individual can create 2^31 files 

Some popular filesystems can't even hold so many entries on the entire disk, 
much less within a single directory.

Also, think about how much space would AT LEAST take to store the filesystem 
entry describing the file.

The ONLY way you could see something like this is memory corruption or an 
enormous bug somewhere in the kernel (if you directly return an int with number 
of files) Foundation (if you are returning NSArray's count) or runtime (if a 
bug exists with returning values).

And in each of these cases you have to worry FAR before your delegate function 
gets called. :-)

You only need to check if:
A) you directly return a number previously read from a file
B) you directly return a number previously read from the network
C) and most of all, because it's way too easy for errors to occur there, if you 
directly return a number previously read from an external device (e.g. over 
rs232:  a robot, or a modem, or a radio transceiver).

And in each case I would check the value when receiving it/reading it -- not 
when returning it. And I'd avoid directly returning the value, instead just 
reading entries and adding them slowly to an array, then returning array's 

That's how I see it, at least. :-)


Ivan Vučica
via phone

reply via email to

[Prev in Thread] Current Thread [Next in Thread]