[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"
<sebastia@l00-bugdead-prods.de> wrote:
>
> On Sunday, February 10, 2013 07:37 CET, Richard Frith-Macdonald
> <richard@tiptree.demon.co.uk> 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
count.
That's how I see it, at least. :-)
Regards,
Ivan Vučica
via phone