Folks, this is getting nowhere.
Chris Hanson (an apple engineer BTW) and Clark (and many others) have
stated the correct answer (simply summarized below)
time to put this one to rest. there is nothing to argue about here.
scott
On Jun 11, 2008, at 8:45 AM, Clark Cox wrote:
If you're goi
On Jun 11, 2008, at 12:29 AM, Jim Puls wrote:
For that matter, it may be worth pointing out John's confusion
between "sloppy" and "incorrect". He makes a decent point that
returning a mutable object when the method definition specifies an
immutable one is sloppy and, indeed, fraught with p
On Wed, Jun 11, 2008 at 12:01 AM, John Engelhart
<[EMAIL PROTECTED]> wrote:
>
> On Jun 10, 2008, at 11:28 AM, Charles Srstka wrote:
>>
>> I think the problem is that if NSArray has +[NSArray array] returning an
>> NSArray, then NSMutableArray has to return an NSArray also, since it can't
>> have a
On Jun 11, 2008, at 2:01 AM, John Engelhart wrote:
If you declare a method prototype as '-(NSArray *)resultsArray',
then you have explicitly communicated that a NSArray is going to be
returned. Not a NSMutableArray. Not 'Jimmies groovy array with red
pin stripes'. A NSArray. Period. A NS
On Jun 11, 2008, at 3:01 AM, John Engelhart wrote:
-(MyObject *)copyAndCombineWith:(MyObject *)object
{
MyObject *copy = malloc(sizeof(MyObject));
memcpy(copy, object, sizeof(MyObject));
copy->answer += answer;
copy->integerRING += integerRing;
return(copy);
}
Do not use malloc() to instan
On Wed, Jun 11, 2008 at 8:01 AM, John Engelhart
<[EMAIL PROTECTED]> wrote:
> A return type of NSArray * means something very explicit. "But all you can
> expect is an object that behaves like a NSArray, so returning a subclass of
> NSArray, like NSMutableArray, is perfectly legal!" You're exactl
Le 11 juin 08 à 09:01, John Engelhart a écrit :
On Jun 10, 2008, at 11:28 AM, Charles Srstka wrote:
I think the problem is that if NSArray has +[NSArray array]
returning an NSArray, then NSMutableArray has to return an NSArray
also, since it can't have a different method signature for th
On 11 Jun 2008, at 5:01 pm, John Engelhart wrote:
If you declare a method prototype as '-(NSArray *)resultsArray',
then you have explicitly communicated that a NSArray is going to be
returned. Not a NSMutableArray. Not 'Jimmies groovy array with red
pin stripes'. A NSArray. Period. A NS
On Jun 11, 2008, at 12:15 AM, Chris Hanson wrote:
This whole business about '(NSArray *) means NSArray AND any of
it's subclasses' is the result of sloppy thinking and confusing
'able to' with 'as per spec'.
No, you are wrong. It really is "per spec." That is an intentional
capability i
On Jun 11, 2008, at 12:01 AM, John Engelhart wrote:
This whole business about '(NSArray *) means NSArray AND any of it's
subclasses' is the result of sloppy thinking and confusing 'able to'
with 'as per spec'.
No, you are wrong. It really is "per spec." That is an intentional
capability
On Jun 10, 2008, at 11:28 AM, Charles Srstka wrote:
I think the problem is that if NSArray has +[NSArray array]
returning an NSArray, then NSMutableArray has to return an NSArray
also, since it can't have a different method signature for the same
method. As a result, if you called +[NSMut
On Tue, Jun 10, 2008 at 4:28 PM, Charles Srstka
<[EMAIL PROTECTED]> wrote:
> I think the problem is that if NSArray has +[NSArray array] returning an
> NSArray, then NSMutableArray has to return an NSArray also, since it can't
> have a different method signature for the same method. As a result, i
On Tuesday, June 10, 2008, at 08:29AM, "Charles Srstka" <[EMAIL PROTECTED]>
wrote:
>On Jun 9, 2008, at 5:55 PM, Hamish Allan wrote:
>
>> Sure. But it gives you *more* information than if it just returns
>> "id". I agree with you in all other respects of your post, but I don't
>> agree that +[NSA
On Jun 9, 2008, at 5:55 PM, Hamish Allan wrote:
Sure. But it gives you *more* information than if it just returns
"id". I agree with you in all other respects of your post, but I don't
agree that +[NSArray array] returns "id" because if it returned
"NSArray *" you'd have to have a separate decla
On Jun 9, 2008, at 1:39 PM, Chris Hanson wrote:
It is perfectly legal to return an NSMutableArray from a
hypothetical +(NSArray *)array method.
However, all the sender of that +(NSArray *)array message can know
is that the result can be treated as an NSArray. It can't know
whether an NSA
On Mon, Jun 9, 2008 at 7:39 PM, Chris Hanson <[EMAIL PROTECTED]> wrote:
> It is perfectly legal to return an NSMutableArray from a hypothetical
> +(NSArray *)array method.
>
> However, all the sender of that +(NSArray *)array message can know is that
> the result can be treated as an NSArray. It
On Jun 9, 2008, at 11:17 AM, Hamish Allan wrote:
On Mon, Jun 9, 2008 at 7:02 PM, Chris Hanson <[EMAIL PROTECTED]> wrote:
The reason these kinds of methods have a return type of (id) is
that there
is no way to say "returns an object of the receiver's class." For
example,
+[NSArray array] re
On Mon, Jun 9, 2008 at 7:02 PM, Chris Hanson <[EMAIL PROTECTED]> wrote:
> The reason these kinds of methods have a return type of (id) is that there
> is no way to say "returns an object of the receiver's class." For example,
> +[NSArray array] returns (id) rather than (NSArray *) because otherwi
On Jun 9, 2008, at 10:24 AM, John Engelhart wrote:
This is not a bug. This is fundamental to how object-oriented
programming works! You should always be able to pass an instance
of a subclass wherever an instance of the superclass is expected.
You're mistaken. You have statically typed t
On Jun 9, 2008, at 6:51 AM, Chris Hanson wrote:
On Jun 9, 2008, at 12:56 AM, John Engelhart wrote:
The semantics are preserved and identical results are calculated
(the 'meaning' is the same). The semantics do not require square()
to literally be called each time.
Yes, that is very clea
On Jun 9, 2008, at 2:56 AM, John Engelhart wrote:
Well, in the case of your example, you have a bug: You have
statically typed the class to NSArray, not your subclass. If one
applies the 'attribute only applies to the class it was specified
for' rule:
By statically typing the class to NS
On 9 Jun 2008, at 00:53, Chris Kane wrote:
On 7 Jun 2008, at 09:07, Antonio Nunes wrote:
On 7 Jun 2008, at 06:16, Ken Thomases wrote:
The issue is, how can one know when this technique is necessary?
By proper documentation. As Bill mentioned earlier, the
documentation needs to mention this
On Jun 9, 2008, at 12:56 AM, John Engelhart wrote:
The semantics are preserved and identical results are calculated
(the 'meaning' is the same). The semantics do not require square()
to literally be called each time.
Yes, that is very clear, because the compiler can have full knowledge
t
On Jun 8, 2008, at 10:03 PM, John Engelhart wrote:
The result from [data self] is invariant, it does not matter if it
is executed immediately after the object is instantiated or just
before [data release], the result is always the same.
There is no way in the Objective-C language as it curr
Le 9 juin 08 à 09:56, John Engelhart a écrit :
On Jun 8, 2008, at 11:48 PM, Chris Hanson wrote:
On Jun 8, 2008, at 5:39 PM, John Engelhart wrote:
On Jun 7, 2008, at 7:11 PM, Chris Hanson wrote:
This won't happen because each message expression -- just as with
function-call expressions -
On Jun 8, 2008, at 11:48 PM, Chris Hanson wrote:
On Jun 8, 2008, at 5:39 PM, John Engelhart wrote:
On Jun 7, 2008, at 7:11 PM, Chris Hanson wrote:
This won't happen because each message expression -- just as with
function-call expressions -- is a sequence point. The compiler
can't know
Date: Mon, 9 Jun 2008 01:03:16 -0400
From: John Engelhart <[EMAIL PROTECTED]>
On Jun 7, 2008, at 10:10 PM, Michael Ash wrote:
If you don't like undefined behavior, then C-based languages are a
poor choice. If you don't like nondeterministic object lifetimes,
then
garbage collection is a poor
On Jun 7, 2008, at 10:10 PM, Michael Ash wrote:
On Sat, Jun 7, 2008 at 6:37 PM, Hamish Allan <[EMAIL PROTECTED]> wrote:
On Sat, Jun 7, 2008 at 7:35 PM, Michael Ash <[EMAIL PROTECTED]>
wrote:
This is pretty nitpicky. If it's in scope but you don't use it, then
it doesn't matter. Kind of lik
On Jun 8, 2008, at 5:39 PM, John Engelhart wrote:
On Jun 7, 2008, at 7:11 PM, Chris Hanson wrote:
This won't happen because each message expression -- just as with
function-call expressions -- is a sequence point. The compiler
can't know what side-effects [data self] might have, so it can'
On Jun 7, 2008, at 7:11 PM, Chris Hanson wrote:
On Jun 6, 2008, at 5:36 PM, Quincey Morris wrote:
A little inner voice insists on asking, though, how we know some
future version of the compiler might not optimize '[data self]'
upwards before the loop, if it decides that nothing inside the
On Jun 7, 2008, at 6:59, Ricky Sharp wrote:
I will hope though that within the context of say memcpy, that the
GC thread could not collect data. For example, the following
should be safe:
memcpy(myLocalGCAwareBuffer, [data bytes], numberOfBytes);
No. This is equivalent to:
void *tmp0734
On 8 Jun 2008, at 01:23, Bill Bumgarner wrote:
One of the tenets of GCC is that *it controls the layout of the
stack always* and this is done quite explicitly because of
performance.
I think this is the crucial point when considering how any GC will
work with gcc.
If gcc controls the s
On Sun, Jun 8, 2008 at 3:10 AM, Michael Ash <[EMAIL PROTECTED]> wrote:
> In many cases, including this one, the release build is actually
> exposing faulty code, whereas the debug build is hiding it by working
> as the programmer wants it to despite the code not actually being
> correct.
My thank
On Sun, Jun 8, 2008 at 1:23 AM, Bill Bumgarner <[EMAIL PROTECTED]> wrote:
> Consider:
>
> {
>int foo;
>
>... calculate on foo ...
>
>int bar = getirdone(foo);
>
>while(1) {
>func(bar);
>func2(bar);
>... etc ...
>}
> }
>
> Without being able to recycle th
Hi Peter,
On Sun, Jun 8, 2008 at 1:15 AM, Peter Duniho <[EMAIL PROTECTED]> wrote:
> Maybe it's just because I've been using GC systems more than you have, and
> so I've gotten used to thinking about memory allocations in the paradigm
> that GC systems impose.
I'm starting to realise that this is
On Jun 7, 2008, at 17:23, Bill Bumgarner wrote:
As well, if foo / bar fall in a register, then those registers would
have to be preserved for all of the while loop, too, either by not
being available to the bulk of the program (which raises some
serious codegen issues) or being moved out/i
On Sat, Jun 7, 2008 at 6:37 PM, Hamish Allan <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 7, 2008 at 7:35 PM, Michael Ash <[EMAIL PROTECTED]> wrote:
>
>> This is pretty nitpicky. If it's in scope but you don't use it, then
>> it doesn't matter. Kind of like a Zen koan: if an object is collected
>> in t
On Jun 6, 2008, at 5:36 PM, Quincey Morris wrote:
A little inner voice insists on asking, though, how we know some
future version of the compiler might not optimize '[data self]'
upwards before the loop, if it decides that nothing inside the loop
references anything non-local:
This won't
On Jun 7, 2008, at 3:51 PM, Hamish Allan wrote:
Sorry to reply to myself, but I just remembered that pointers in
registers are also in the root set! That said, I don't think it
changes the substance of my proposal: that stack variables (i.e.
variables semantically placed on the stack by the progr
Date: Sat, 7 Jun 2008 23:24:22 +0100
From: "Hamish Allan" <[EMAIL PROTECTED]>
Whenever you write documentation in a natural language, there is scope
for ambiguity. This particular technical specification is only
mentioned in a single sentence:
"The root set is comprised of all objects reachable
On Sat, Jun 7, 2008 at 11:24 PM, Hamish Allan <[EMAIL PROTECTED]> wrote:
> Sure, you could design NSData differently to mask a design problem in
> GC. But GC won't be easier to use than retain/release/autorelease
> without simple rules like "if you declare it on the stack, it's in the
> root set,
On Sat, Jun 7, 2008 at 7:35 PM, Michael Ash <[EMAIL PROTECTED]> wrote:
> This is pretty nitpicky. If it's in scope but you don't use it, then
> it doesn't matter. Kind of like a Zen koan: if an object is collected
> in the forest but nobody is pointing to it anymore, does it make a
> sound?
:)
I
On Sat, Jun 7, 2008 at 7:34 PM, Peter Duniho <[EMAIL PROTECTED]> wrote:
>> Date: Sat, 7 Jun 2008 15:31:43 +0100
>> From: "Hamish Allan" <[EMAIL PROTECTED]>
>>
>> We're just interpreting this promise differently. To my mind, while
>> the variable is still in scope, I *do* have a pointer to the obje
On Jun 7, 2008, at 2:07 PM, Jean-Daniel Dupas wrote:
Le 7 juin 08 à 20:30, Michael Ash a écrit :
On Sat, Jun 7, 2008 at 9:59 AM, Ricky Sharp <[EMAIL PROTECTED]> wrote:
I will hope though that within the context of say memcpy, that the
GC thread
could not collect data. For example, the fo
On Jun 7, 2008, at 1:30 PM, Michael Ash wrote:
On Sat, Jun 7, 2008 at 9:59 AM, Ricky Sharp <[EMAIL PROTECTED]> wrote:
Finally, I think that usages of NSMutableData may also be a bit
tricky. In
my case I'll probably just obtain a copy of its bytes, manipulate
them and
then copy the result
Le 7 juin 08 à 20:30, Michael Ash a écrit :
On Sat, Jun 7, 2008 at 9:59 AM, Ricky Sharp <[EMAIL PROTECTED]> wrote:
I will hope though that within the context of say memcpy, that the
GC thread
could not collect data. For example, the following should be safe:
memcpy(myLocalGCAwareBuffer, [d
On Sat, Jun 7, 2008 at 2:19 PM, Quincey Morris
<[EMAIL PROTECTED]> wrote:
> The consequence of this should be either:
>
> (a) [data bytes] must promise to return a collectable object (so that the
> 'bytes' reference keeps it alive), or
>
> (b) [data bytes] must lock (pseudo-retain) something intern
On Sat, Jun 7, 2008 at 10:31 AM, Hamish Allan <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 7, 2008 at 2:18 PM, Michael Ash <[EMAIL PROTECTED]> wrote:
>
>> The business about scanning the stack is essentially an
>> implementation detail; the promise that is being made is that objects
>> which you're sti
Date: Sat, 7 Jun 2008 15:31:43 +0100
From: "Hamish Allan" <[EMAIL PROTECTED]>
On Sat, Jun 7, 2008 at 2:18 PM, Michael Ash <[EMAIL PROTECTED]>
wrote:
The business about scanning the stack is essentially an
implementation detail; the promise that is being made is that objects
which you're stil
On Sat, Jun 7, 2008 at 9:59 AM, Ricky Sharp <[EMAIL PROTECTED]> wrote:
> I will hope though that within the context of say memcpy, that the GC thread
> could not collect data. For example, the following should be safe:
>
> memcpy(myLocalGCAwareBuffer, [data bytes], numberOfBytes);
Not at all. The
On Jun 7, 2008, at 04:34, Michael Ash wrote:
Actually I think that it is about the char * pointer, and this bug
should be considered an NSData bug rather than a compiler bug or a GC
bug. The fact that it's really a design bug in NSData rather than
something that can be easily fixed definitely m
On Jun 6, 2008, at 7:27 PM, Quincey Morris wrote:
On Jun 6, 2008, at 15:48, Bill Bumgarner wrote:
The garbage collector does not currently interpret inner pointers
as something that can keep an encapsulating object alive. Thus,
the behavior is undefined and that it changes between debug
On Sat, Jun 7, 2008 at 2:18 PM, Michael Ash <[EMAIL PROTECTED]> wrote:
> The business about scanning the stack is essentially an
> implementation detail; the promise that is being made is that objects
> which you're still pointing to won't go away.
We're just interpreting this promise differently
On Jun 7, 2008, at 8:18 AM, Michael Ash wrote:
It *does* do this. The error is not in the GC, but rather in the
assumption that "declared in the current scope" is equivalent to "is
on the stack frame". This assumption is not valid. The fact that you
can't make this assumption is extremely incon
On Sat, Jun 7, 2008 at 8:47 AM, Hamish Allan <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 7, 2008 at 12:34 PM, Michael Ash <[EMAIL PROTECTED]> wrote:
>
>> The problem here is
>> that you're expecting one pointer to keep a *different* pointer live,
>> which the GC does not make any guarantees about.
>
>
On Sat, Jun 7, 2008 at 12:34 PM, Michael Ash <[EMAIL PROTECTED]> wrote:
> The problem here is
> that you're expecting one pointer to keep a *different* pointer live,
> which the GC does not make any guarantees about.
Pre garbage collection, this was straightforward: as long as you
retain your NSD
On Sat, Jun 7, 2008 at 12:42 AM, Bill Bumgarner <[EMAIL PROTECTED]> wrote:
> The easiest way to do this is to simply to use data once after the for()
> loop:
>
>NSData* data = ;
>const unsigned char* bytes = [data bytes];
>NSUInteger count = [data length];
>for (NSU
On Sat, Jun 7, 2008 at 12:31 AM, Bill Bumgarner <[EMAIL PROTECTED]> wrote:
> Yes, it is an exceedingly important optimization. Most likely, that stack
> slot is being reused by some variable later on.
I can see how this might be "exceedingly important" for deeply
recursive functions, but for the
On Sat, Jun 7, 2008 at 7:13 AM, Ken Thomases <[EMAIL PROTECTED]> wrote:
> Nobody is claiming that it should. It's not about the char* pointer. It's
> about the NSData* pointer.
Actually I think that it is about the char * pointer, and this bug
should be considered an NSData bug rather than a com
On Jun 7, 2008, at 3:41 AM, Quincey Morris wrote:
On Jun 7, 2008, at 00:07, Antonio Nunes wrote:
Although I maybe did not make it that clear, I actually meant my
suggestion also as a question. I'm surprised no-one else suggested
to temporarily turn of garbage collection for this pointer. I'
On Jun 7, 2008, at 12:03 AM, Bill Bumgarner wrote:
On Jun 6, 2008, at 9:16 PM, Ken Thomases wrote:
And... we're back to retain/release.
The issue is, how can one know when this technique is necessary?
The supposed rules of GC are, if it's in a stack variable, it's
safe. The compiler here
On Jun 7, 2008, at 00:07, Antonio Nunes wrote:
Although I maybe did not make it that clear, I actually meant my
suggestion also as a question. I'm surprised no-one else suggested
to temporarily turn of garbage collection for this pointer. I'm
curious as to why Bill suggested his solution r
I'm fairly satisfied with Bill's (and others') suggested workarounds
about how to keep the object from being collected, but if I might
ramble just a little:
On Jun 6, 2008, at 22:03, Bill Bumgarner wrote:
On Jun 6, 2008, at 9:16 PM, Ken Thomases wrote:
And... we're back to retain/release.
On 7 Jun 2008, at 06:16, Ken Thomases wrote:
On Jun 6, 2008, at 10:48 PM, Antonio Nunes wrote:
Why not explicitly turn off collection for the data pointer:
NSData* data = ;
[[NSGarbageCollector defaultCollector]
disableCollectorForPointer:data];
const unsigned char* bytes = [data bytes];
NS
On Jun 6, 2008, at 9:16 PM, Ken Thomases wrote:
And... we're back to retain/release.
The issue is, how can one know when this technique is necessary?
The supposed rules of GC are, if it's in a stack variable, it's
safe. The compiler here is doing something behind the programmer's
back, wh
On Jun 6, 2008, at 10:48 PM, Antonio Nunes wrote:
On 7 Jun 2008, at 01:42, Bill Bumgarner wrote:
The easiest way to do this is to simply to use data once after the
for() loop:
NSData* data = ;
const unsigned char* bytes = [data bytes];
NSUInteger count = [data length
On Jun 6, 2008, at 5:36 PM, Quincey Morris wrote:
Thanks, and to Shawn for the same suggestion. It's a pragmatic
solution I can deal with.
A little inner voice insists on asking, though, how we know some
future version of the compiler might not optimize '[data self]'
upwards before the loop,
On 7 Jun 2008, at 01:42, Bill Bumgarner wrote:
The easiest way to do this is to simply to use data once after the
for() loop:
NSData* data = ;
const unsigned char* bytes = [data bytes];
NSUInteger count = [data length];
for (NSUInteger i = 0; i < count; i++)
On Jun 6, 2008, at 7:05 PM, Ricky Sharp wrote:
On Jun 6, 2008, at 6:42 PM, Bill Bumgarner wrote:
Sorry -- let me clarify. If the was either released in a
different thread or if were explicitly released in the above
code, then you would see the same crash. I didn't mean to imply
t
On Jun 6, 2008, at 16:42, Bill Bumgarner wrote:
The easiest way to do this is to simply to use data once after the
for() loop:
NSData* data = ;
const unsigned char* bytes = [data bytes];
NSUInteger count = [data length];
for (NSUInteger i = 0; i < count; i++)
On Jun 6, 2008, at 6:42 PM, Bill Bumgarner wrote:
Sorry -- let me clarify. If the was either released in a
different thread or if were explicitly released in the above
code, then you would see the same crash. I didn't mean to imply
that would be released under non-GC without some
On Fri, Jun 6, 2008 at 4:27 PM, Quincey Morris
<[EMAIL PROTECTED]> wrote:
>
> On Jun 6, 2008, at 15:48, Bill Bumgarner wrote:
>
>> In any case, you need to make sure that stays alive throughout the
>> entire lifespan of the bytes pointer.
>
> But the puzzling question is: how?
CFRetain/CFRelease
On Jun 6, 2008, at 4:24 PM, Ricky Sharp wrote:
On Jun 6, 2008, at 5:48 PM, Bill Bumgarner wrote:
On Jun 6, 2008, at 3:23 PM, Quincey Morris wrote:
In a GC-only app, I frequently use a pattern along these lines:
NSData* data = ;
const unsigned char* bytes = [data bytes];
On Fri, Jun 6, 2008 at 4:27 PM, Quincey Morris
<[EMAIL PROTECTED]> wrote:
> But the puzzling question is: how?
Send a message to the NSData object after the block is done with the
byte pointer. ([data self])
-Shawn
___
Cocoa-dev mailing list (Cocoa-de
On Jun 6, 2008, at 4:18 PM, Hamish Allan wrote:
On Fri, Jun 6, 2008 at 11:48 PM, Bill Bumgarner <[EMAIL PROTECTED]> wrote:
The garbage collector does not currently interpret inner pointers as
something that can keep an encapsulating object alive.
But it's not the inner pointers I would expect t
On Jun 6, 2008, at 5:24 PM, Ricky Sharp wrote:
I'm a bit confused by this. In non-GC, data would not be released
during the loop execution. Let's assume that it was autoreleased
during the 'get it from somewhere'. It would only be actually
released when execution returns to the main run
On Jun 6, 2008, at 15:48, Bill Bumgarner wrote:
The garbage collector does not currently interpret inner pointers as
something that can keep an encapsulating object alive. Thus, the
behavior is undefined and that it changes between debug and release
builds -- between optimization levels o
On Jun 6, 2008, at 5:48 PM, Bill Bumgarner wrote:
On Jun 6, 2008, at 3:23 PM, Quincey Morris wrote:
In a GC-only app, I frequently use a pattern along these lines:
NSData* data = ;
const unsigned char* bytes = [data bytes];
NSUInteger count = [data length];
for
On Fri, Jun 6, 2008 at 11:48 PM, Bill Bumgarner <[EMAIL PROTECTED]> wrote:
> The garbage collector does not currently interpret inner pointers as
> something that can keep an encapsulating object alive.
But it's not the inner pointers I would expect to keep the object
alive -- it's the fact that
On Jun 6, 2008, at 3:23 PM, Quincey Morris wrote:
In a GC-only app, I frequently use a pattern along these lines:
NSData* data = ;
const unsigned char* bytes = [data bytes];
NSUInteger count = [data length];
for (NSUInteger i = 0; i < count; i++)
s
In a GC-only app, I frequently use a pattern along these lines:
NSData* data = ;
const unsigned char* bytes = [data bytes];
NSUInteger count = [data length];
for (NSUInteger i = 0; i < count; i++)
something = bytes [i];
The "release" (but not the "
81 matches
Mail list logo
