Comments on: ^ Blocks Tips & Tricks

By: Jonathan Lehr

Jonathan Lehr — Sat, 12 Sep 2009 16:53:49 +0000

Thanks for the great article! One minor note: The Grand Central Dispatch technology brief linked at the top appears to have been superseded by a later version, and because the date is incorporated in the filename the older link doesn’t work anymore. Here’s a link to the updated file:

http://images.apple.com/macosx/technology/docs/GrandCentral_TB_brief_20090903.pdf

By: Ben Holt

Ben Holt — Sun, 30 Aug 2009 21:39:11 +0000

One potential gotcha regarding recursive blocks (example 7): if the block might be copied for any reason or could outlive the scope of the current stack frame, you must store a copy of the block in your reference variable.

By: Joachim Bengtsson

Joachim Bengtsson — Sat, 29 Aug 2009 18:37:38 +0000

As an addition to #2 and #5 is the case of storing a block in a collection like NSArray or NSDictionary longer than the block will survive on the stack; since they all use -[retain], the block needs to be moved to the heap first, like so:

NSArray *thingsToDo = [NSArray arrayWithObjects:
[[^ { NSLog(@"Hello"); } copy] autorelease],
[[^ { NSLog(@"World!"); } copy] autorelease],
nil];

I write about that and more in my own blocks guide over at http://thirdcog.eu/pwcblocks/

By: John C. Randolph

John C. Randolph — Sat, 29 Aug 2009 18:18:09 +0000

Thanks, yuji. I wasn’t clear on that.

-jcr

By: yuji

yuji — Sat, 29 Aug 2009 16:42:17 +0000

No, only the context (captured local variables, etc.) of the block is on the stack. The code is still on the executable section. The context on the stack only has a pointer to the said code.

By: John C. Randolph

John C. Randolph — Sat, 29 Aug 2009 11:17:11 +0000

So, it seems to me that since blocks are allocated on the stack, and they’re executable, using them means the stack can’t be in memory that’s marked as non-executable. Is this a security hazard, or are the classic stack-smashing attacks a non-issue these days?

-jcr