[NFC] Trim trailing whitespace in *.rst
[platform/upstream/llvm.git] / clang / docs / Block-ABI-Apple.rst
1 ==================================
2 Block Implementation Specification
3 ==================================
4
5 .. contents::
6    :local:
7
8 History
9 =======
10
11 * 2008/7/14 - created.
12 * 2008/8/21 - revised, C++.
13 * 2008/9/24 - add ``NULL`` ``isa`` field to ``__block`` storage.
14 * 2008/10/1 - revise block layout to use a ``static`` descriptor structure.
15 * 2008/10/6 - revise block layout to use an unsigned long int flags.
16 * 2008/10/28 - specify use of ``_Block_object_assign`` and
17   ``_Block_object_dispose`` for all "Object" types in helper functions.
18 * 2008/10/30 - revise new layout to have invoke function in same place.
19 * 2008/10/30 - add ``__weak`` support.
20 * 2010/3/16 - rev for stret return, signature field.
21 * 2010/4/6 - improved wording.
22 * 2013/1/6 - improved wording and converted to rst.
23
24 This document describes the Apple ABI implementation specification of Blocks.
25
26 The first shipping version of this ABI is found in Mac OS X 10.6, and shall be
27 referred to as 10.6.ABI. As of 2010/3/16, the following describes the ABI
28 contract with the runtime and the compiler, and, as necessary, will be referred
29 to as ABI.2010.3.16.
30
31 Since the Apple ABI references symbols from other elements of the system, any
32 attempt to use this ABI on systems prior to SnowLeopard is undefined.
33
34 High Level
35 ==========
36
37 The ABI of ``Blocks`` consist of their layout and the runtime functions required
38 by the compiler.  A ``Block`` of type ``R (^)(P...)`` consists of a structure of
39 the following form:
40
41 .. code-block:: c
42
43     struct Block_literal_1 {
44         void *isa; // initialized to &_NSConcreteStackBlock or &_NSConcreteGlobalBlock
45         int flags;
46         int reserved;
47         R (*invoke)(struct Block_literal_1 *, P...);
48         struct Block_descriptor_1 {
49             unsigned long int reserved;     // NULL
50             unsigned long int size;         // sizeof(struct Block_literal_1)
51             // optional helper functions
52             void (*copy_helper)(void *dst, void *src);     // IFF (1<<25)
53             void (*dispose_helper)(void *src);             // IFF (1<<25)
54             // required ABI.2010.3.16
55             const char *signature;                         // IFF (1<<30)
56         } *descriptor;
57         // imported variables
58     };
59
60 The following flags bits are in use thusly for a possible ABI.2010.3.16:
61
62 .. code-block:: c
63
64     enum {
65         // Set to true on blocks that have captures (and thus are not true
66         // global blocks) but are known not to escape for various other
67         // reasons. For backward compatibility with old runtimes, whenever
68         // BLOCK_IS_NOESCAPE is set, BLOCK_IS_GLOBAL is set too. Copying a
69         // non-escaping block returns the original block and releasing such a
70         // block is a no-op, which is exactly how global blocks are handled.
71         BLOCK_IS_NOESCAPE      =  (1 << 23),
72
73         BLOCK_HAS_COPY_DISPOSE =  (1 << 25),
74         BLOCK_HAS_CTOR =          (1 << 26), // helpers have C++ code
75         BLOCK_IS_GLOBAL =         (1 << 28),
76         BLOCK_HAS_STRET =         (1 << 29), // IFF BLOCK_HAS_SIGNATURE
77         BLOCK_HAS_SIGNATURE =     (1 << 30),
78     };
79
80 In 10.6.ABI the (1<<29) was usually set and was always ignored by the runtime -
81 it had been a transitional marker that did not get deleted after the
82 transition. This bit is now paired with (1<<30), and represented as the pair
83 (3<<30), for the following combinations of valid bit settings, and their
84 meanings:
85
86 .. code-block:: c
87
88     switch (flags & (3<<29)) {
89       case (0<<29):      10.6.ABI, no signature field available
90       case (1<<29):      10.6.ABI, no signature field available
91       case (2<<29): ABI.2010.3.16, regular calling convention, presence of signature field
92       case (3<<29): ABI.2010.3.16, stret calling convention, presence of signature field,
93     }
94
95 The signature field is not always populated.
96
97 The following discussions are presented as 10.6.ABI otherwise.
98
99 ``Block`` literals may occur within functions where the structure is created in
100 stack local memory.  They may also appear as initialization expressions for
101 ``Block`` variables of global or ``static`` local variables.
102
103 When a ``Block`` literal expression is evaluated the stack based structure is
104 initialized as follows:
105
106 1. A ``static`` descriptor structure is declared and initialized as follows:
107
108   a. The ``invoke`` function pointer is set to a function that takes the
109   ``Block`` structure as its first argument and the rest of the arguments (if
110   any) to the ``Block`` and executes the ``Block`` compound statement.
111
112   b. The ``size`` field is set to the size of the following ``Block`` literal
113   structure.
114
115   c. The ``copy_helper`` and ``dispose_helper`` function pointers are set to
116   respective helper functions if they are required by the ``Block`` literal.
117
118 2. A stack (or global) ``Block`` literal data structure is created and
119    initialized as follows:
120
121    a. The ``isa`` field is set to the address of the external
122    ``_NSConcreteStackBlock``, which is a block of uninitialized memory supplied
123    in ``libSystem``, or ``_NSConcreteGlobalBlock`` if this is a static or file
124    level ``Block`` literal.
125
126    b. The ``flags`` field is set to zero unless there are variables imported
127    into the ``Block`` that need helper functions for program level
128    ``Block_copy()`` and ``Block_release()`` operations, in which case the
129    (1<<25) flags bit is set.
130
131 As an example, the ``Block`` literal expression:
132
133 .. code-block:: c
134
135     ^ { printf("hello world\n"); }
136
137 would cause the following to be created on a 32-bit system:
138
139 .. code-block:: c
140
141     struct __block_literal_1 {
142         void *isa;
143         int flags;
144         int reserved;
145         void (*invoke)(struct __block_literal_1 *);
146         struct __block_descriptor_1 *descriptor;
147     };
148
149     void __block_invoke_1(struct __block_literal_1 *_block) {
150         printf("hello world\n");
151     }
152
153     static struct __block_descriptor_1 {
154         unsigned long int reserved;
155         unsigned long int Block_size;
156     } __block_descriptor_1 = { 0, sizeof(struct __block_literal_1) };
157
158 and where the ``Block`` literal itself appears:
159
160 .. code-block:: c
161
162     struct __block_literal_1 _block_literal = {
163          &_NSConcreteStackBlock,
164          (1<<29), <uninitialized>,
165          __block_invoke_1,
166          &__block_descriptor_1
167     };
168
169 A ``Block`` imports other ``Block`` references, ``const`` copies of other
170 variables, and variables marked ``__block``.  In Objective-C, variables may
171 additionally be objects.
172
173 When a ``Block`` literal expression is used as the initial value of a global
174 or ``static`` local variable, it is initialized as follows:
175
176 .. code-block:: c
177
178     struct __block_literal_1 __block_literal_1 = {
179           &_NSConcreteGlobalBlock,
180           (1<<28)|(1<<29), <uninitialized>,
181           __block_invoke_1,
182           &__block_descriptor_1
183     };
184
185 that is, a different address is provided as the first value and a particular
186 (1<<28) bit is set in the ``flags`` field, and otherwise it is the same as for
187 stack based ``Block`` literals.  This is an optimization that can be used for
188 any ``Block`` literal that imports no ``const`` or ``__block`` storage
189 variables.
190
191 Imported Variables
192 ==================
193
194 Variables of ``auto`` storage class are imported as ``const`` copies.  Variables
195 of ``__block`` storage class are imported as a pointer to an enclosing data
196 structure.  Global variables are simply referenced and not considered as
197 imported.
198
199 Imported ``const`` copy variables
200 ---------------------------------
201
202 Automatic storage variables not marked with ``__block`` are imported as
203 ``const`` copies.
204
205 The simplest example is that of importing a variable of type ``int``:
206
207 .. code-block:: c
208
209     int x = 10;
210     void (^vv)(void) = ^{ printf("x is %d\n", x); }
211     x = 11;
212     vv();
213
214 which would be compiled to:
215
216 .. code-block:: c
217
218     struct __block_literal_2 {
219         void *isa;
220         int flags;
221         int reserved;
222         void (*invoke)(struct __block_literal_2 *);
223         struct __block_descriptor_2 *descriptor;
224         const int x;
225     };
226
227     void __block_invoke_2(struct __block_literal_2 *_block) {
228         printf("x is %d\n", _block->x);
229     }
230
231     static struct __block_descriptor_2 {
232         unsigned long int reserved;
233         unsigned long int Block_size;
234     } __block_descriptor_2 = { 0, sizeof(struct __block_literal_2) };
235
236 and:
237
238 .. code-block:: c
239
240     struct __block_literal_2 __block_literal_2 = {
241           &_NSConcreteStackBlock,
242           (1<<29), <uninitialized>,
243           __block_invoke_2,
244           &__block_descriptor_2,
245           x
246      };
247
248 In summary, scalars, structures, unions, and function pointers are generally
249 imported as ``const`` copies with no need for helper functions.
250
251 Imported ``const`` copy of ``Block`` reference
252 ----------------------------------------------
253
254 The first case where copy and dispose helper functions are required is for the
255 case of when a ``Block`` itself is imported.  In this case both a
256 ``copy_helper`` function and a ``dispose_helper`` function are needed.  The
257 ``copy_helper`` function is passed both the existing stack based pointer and the
258 pointer to the new heap version and should call back into the runtime to
259 actually do the copy operation on the imported fields within the ``Block``. The
260 runtime functions are all described in :ref:`RuntimeHelperFunctions`.
261
262 A quick example:
263
264 .. code-block:: c
265
266     void (^existingBlock)(void) = ...;
267     void (^vv)(void) = ^{ existingBlock(); }
268     vv();
269
270     struct __block_literal_3 {
271        ...; // existing block
272     };
273
274     struct __block_literal_4 {
275         void *isa;
276         int flags;
277         int reserved;
278         void (*invoke)(struct __block_literal_4 *);
279         struct __block_literal_3 *const existingBlock;
280     };
281
282     void __block_invoke_4(struct __block_literal_2 *_block) {
283        __block->existingBlock->invoke(__block->existingBlock);
284     }
285
286     void __block_copy_4(struct __block_literal_4 *dst, struct __block_literal_4 *src) {
287          //_Block_copy_assign(&dst->existingBlock, src->existingBlock, 0);
288          _Block_object_assign(&dst->existingBlock, src->existingBlock, BLOCK_FIELD_IS_BLOCK);
289     }
290
291     void __block_dispose_4(struct __block_literal_4 *src) {
292          // was _Block_destroy
293          _Block_object_dispose(src->existingBlock, BLOCK_FIELD_IS_BLOCK);
294     }
295
296     static struct __block_descriptor_4 {
297         unsigned long int reserved;
298         unsigned long int Block_size;
299         void (*copy_helper)(struct __block_literal_4 *dst, struct __block_literal_4 *src);
300         void (*dispose_helper)(struct __block_literal_4 *);
301     } __block_descriptor_4 = {
302         0,
303         sizeof(struct __block_literal_4),
304         __block_copy_4,
305         __block_dispose_4,
306     };
307
308 and where said ``Block`` is used:
309
310 .. code-block:: c
311
312     struct __block_literal_4 _block_literal = {
313           &_NSConcreteStackBlock,
314           (1<<25)|(1<<29), <uninitialized>
315           __block_invoke_4,
316           & __block_descriptor_4
317           existingBlock,
318     };
319
320 Importing ``__attribute__((NSObject))`` variables
321 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
322
323 GCC introduces ``__attribute__((NSObject))`` on structure pointers to mean "this
324 is an object".  This is useful because many low level data structures are
325 declared as opaque structure pointers, e.g. ``CFStringRef``, ``CFArrayRef``,
326 etc.  When used from C, however, these are still really objects and are the
327 second case where that requires copy and dispose helper functions to be
328 generated.  The copy helper functions generated by the compiler should use the
329 ``_Block_object_assign`` runtime helper function and in the dispose helper the
330 ``_Block_object_dispose`` runtime helper function should be called.
331
332 For example, ``Block`` foo in the following:
333
334 .. code-block:: c
335
336     struct Opaque *__attribute__((NSObject)) objectPointer = ...;
337     ...
338     void (^foo)(void) = ^{  CFPrint(objectPointer); };
339
340 would have the following helper functions generated:
341
342 .. code-block:: c
343
344     void __block_copy_foo(struct __block_literal_5 *dst, struct __block_literal_5 *src) {
345          _Block_object_assign(&dst->objectPointer, src-> objectPointer, BLOCK_FIELD_IS_OBJECT);
346     }
347
348     void __block_dispose_foo(struct __block_literal_5 *src) {
349          _Block_object_dispose(src->objectPointer, BLOCK_FIELD_IS_OBJECT);
350     }
351
352 Imported ``__block`` marked variables
353 -------------------------------------
354
355 Layout of ``__block`` marked variables
356 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
357
358 The compiler must embed variables that are marked ``__block`` in a specialized
359 structure of the form:
360
361 .. code-block:: c
362
363     struct _block_byref_foo {
364         void *isa;
365         struct Block_byref *forwarding;
366         int flags;   //refcount;
367         int size;
368         typeof(marked_variable) marked_variable;
369     };
370
371 Variables of certain types require helper functions for when ``Block_copy()``
372 and ``Block_release()`` are performed upon a referencing ``Block``.  At the "C"
373 level only variables that are of type ``Block`` or ones that have
374 ``__attribute__((NSObject))`` marked require helper functions.  In Objective-C
375 objects require helper functions and in C++ stack based objects require helper
376 functions. Variables that require helper functions use the form:
377
378 .. code-block:: c
379
380     struct _block_byref_foo {
381         void *isa;
382         struct _block_byref_foo *forwarding;
383         int flags;   //refcount;
384         int size;
385         // helper functions called via Block_copy() and Block_release()
386         void (*byref_keep)(void  *dst, void *src);
387         void (*byref_dispose)(void *);
388         typeof(marked_variable) marked_variable;
389     };
390
391 The structure is initialized such that:
392
393     a. The ``forwarding`` pointer is set to the beginning of its enclosing
394     structure.
395
396     b. The ``size`` field is initialized to the total size of the enclosing
397     structure.
398
399     c. The ``flags`` field is set to either 0 if no helper functions are needed
400     or (1<<25) if they are.
401
402     d. The helper functions are initialized (if present).
403
404     e. The variable itself is set to its initial value.
405
406     f. The ``isa`` field is set to ``NULL``.
407
408 Access to ``__block`` variables from within its lexical scope
409 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
410
411 In order to "move" the variable to the heap upon a ``copy_helper`` operation the
412 compiler must rewrite access to such a variable to be indirect through the
413 structures ``forwarding`` pointer.  For example:
414
415 .. code-block:: c
416
417     int __block i = 10;
418     i = 11;
419
420 would be rewritten to be:
421
422 .. code-block:: c
423
424     struct _block_byref_i {
425       void *isa;
426       struct _block_byref_i *forwarding;
427       int flags;   //refcount;
428       int size;
429       int captured_i;
430     } i = { NULL, &i, 0, sizeof(struct _block_byref_i), 10 };
431
432     i.forwarding->captured_i = 11;
433
434 In the case of a ``Block`` reference variable being marked ``__block`` the
435 helper code generated must use the ``_Block_object_assign`` and
436 ``_Block_object_dispose`` routines supplied by the runtime to make the
437 copies. For example:
438
439 .. code-block:: c
440
441     __block void (voidBlock)(void) = blockA;
442     voidBlock = blockB;
443
444 would translate into:
445
446 .. code-block:: c
447
448     struct _block_byref_voidBlock {
449         void *isa;
450         struct _block_byref_voidBlock *forwarding;
451         int flags;   //refcount;
452         int size;
453         void (*byref_keep)(struct _block_byref_voidBlock *dst, struct _block_byref_voidBlock *src);
454         void (*byref_dispose)(struct _block_byref_voidBlock *);
455         void (^captured_voidBlock)(void);
456     };
457
458     void _block_byref_keep_helper(struct _block_byref_voidBlock *dst, struct _block_byref_voidBlock *src) {
459         //_Block_copy_assign(&dst->captured_voidBlock, src->captured_voidBlock, 0);
460         _Block_object_assign(&dst->captured_voidBlock, src->captured_voidBlock, BLOCK_FIELD_IS_BLOCK | BLOCK_BYREF_CALLER);
461     }
462
463     void _block_byref_dispose_helper(struct _block_byref_voidBlock *param) {
464         //_Block_destroy(param->captured_voidBlock, 0);
465         _Block_object_dispose(param->captured_voidBlock, BLOCK_FIELD_IS_BLOCK | BLOCK_BYREF_CALLER)}
466
467 and:
468
469 .. code-block:: c
470
471     struct _block_byref_voidBlock voidBlock = {( .forwarding=&voidBlock, .flags=(1<<25), .size=sizeof(struct _block_byref_voidBlock *),
472         .byref_keep=_block_byref_keep_helper, .byref_dispose=_block_byref_dispose_helper,
473         .captured_voidBlock=blockA )};
474
475     voidBlock.forwarding->captured_voidBlock = blockB;
476
477 Importing ``__block`` variables into ``Blocks``
478 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
479
480 A ``Block`` that uses a ``__block`` variable in its compound statement body must
481 import the variable and emit ``copy_helper`` and ``dispose_helper`` helper
482 functions that, in turn, call back into the runtime to actually copy or release
483 the ``byref`` data block using the functions ``_Block_object_assign`` and
484 ``_Block_object_dispose``.
485
486 For example:
487
488 .. code-block:: c
489
490     int __block i = 2;
491     functioncall(^{ i = 10; });
492
493 would translate to:
494
495 .. code-block:: c
496
497     struct _block_byref_i {
498         void *isa;  // set to NULL
499         struct _block_byref_voidBlock *forwarding;
500         int flags;   //refcount;
501         int size;
502         void (*byref_keep)(struct _block_byref_i *dst, struct _block_byref_i *src);
503         void (*byref_dispose)(struct _block_byref_i *);
504         int captured_i;
505     };
506
507
508     struct __block_literal_5 {
509         void *isa;
510         int flags;
511         int reserved;
512         void (*invoke)(struct __block_literal_5 *);
513         struct __block_descriptor_5 *descriptor;
514         struct _block_byref_i *i_holder;
515     };
516
517     void __block_invoke_5(struct __block_literal_5 *_block) {
518        _block->forwarding->captured_i = 10;
519     }
520
521     void __block_copy_5(struct __block_literal_5 *dst, struct __block_literal_5 *src) {
522          //_Block_byref_assign_copy(&dst->captured_i, src->captured_i);
523          _Block_object_assign(&dst->captured_i, src->captured_i, BLOCK_FIELD_IS_BYREF | BLOCK_BYREF_CALLER);
524     }
525
526     void __block_dispose_5(struct __block_literal_5 *src) {
527          //_Block_byref_release(src->captured_i);
528          _Block_object_dispose(src->captured_i, BLOCK_FIELD_IS_BYREF | BLOCK_BYREF_CALLER);
529     }
530
531     static struct __block_descriptor_5 {
532         unsigned long int reserved;
533         unsigned long int Block_size;
534         void (*copy_helper)(struct __block_literal_5 *dst, struct __block_literal_5 *src);
535         void (*dispose_helper)(struct __block_literal_5 *);
536     } __block_descriptor_5 = { 0, sizeof(struct __block_literal_5) __block_copy_5, __block_dispose_5 };
537
538 and:
539
540 .. code-block:: c
541
542     struct _block_byref_i i = {( .isa=NULL, .forwarding=&i, .flags=0, .size=sizeof(struct _block_byref_i), .captured_i=2 )};
543     struct __block_literal_5 _block_literal = {
544           &_NSConcreteStackBlock,
545           (1<<25)|(1<<29), <uninitialized>,
546           __block_invoke_5,
547           &__block_descriptor_5,
548           &i,
549     };
550
551 Importing ``__attribute__((NSObject))`` ``__block`` variables
552 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
553
554 A ``__block`` variable that is also marked ``__attribute__((NSObject))`` should
555 have ``byref_keep`` and ``byref_dispose`` helper functions that use
556 ``_Block_object_assign`` and ``_Block_object_dispose``.
557
558 ``__block`` escapes
559 ^^^^^^^^^^^^^^^^^^^
560
561 Because ``Blocks`` referencing ``__block`` variables may have ``Block_copy()``
562 performed upon them the underlying storage for the variables may move to the
563 heap.  In Objective-C Garbage Collection Only compilation environments the heap
564 used is the garbage collected one and no further action is required.  Otherwise
565 the compiler must issue a call to potentially release any heap storage for
566 ``__block`` variables at all escapes or terminations of their scope.  The call
567 should be:
568
569 .. code-block:: c
570
571     _Block_object_dispose(&_block_byref_foo, BLOCK_FIELD_IS_BYREF);
572
573 Nesting
574 ^^^^^^^
575
576 ``Blocks`` may contain ``Block`` literal expressions.  Any variables used within
577 inner blocks are imported into all enclosing ``Block`` scopes even if the
578 variables are not used. This includes ``const`` imports as well as ``__block``
579 variables.
580
581 Objective C Extensions to ``Blocks``
582 ====================================
583
584 Importing Objects
585 -----------------
586
587 Objects should be treated as ``__attribute__((NSObject))`` variables; all
588 ``copy_helper``, ``dispose_helper``, ``byref_keep``, and ``byref_dispose``
589 helper functions should use ``_Block_object_assign`` and
590 ``_Block_object_dispose``.  There should be no code generated that uses
591 ``*-retain`` or ``*-release`` methods.
592
593 ``Blocks`` as Objects
594 ---------------------
595
596 The compiler will treat ``Blocks`` as objects when synthesizing property setters
597 and getters, will characterize them as objects when generating garbage
598 collection strong and weak layout information in the same manner as objects, and
599 will issue strong and weak write-barrier assignments in the same manner as
600 objects.
601
602 ``__weak __block`` Support
603 --------------------------
604
605 Objective-C (and Objective-C++) support the ``__weak`` attribute on ``__block``
606 variables.  Under normal circumstances the compiler uses the Objective-C runtime
607 helper support functions ``objc_assign_weak`` and ``objc_read_weak``.  Both
608 should continue to be used for all reads and writes of ``__weak __block``
609 variables:
610
611 .. code-block:: c
612
613     objc_read_weak(&block->byref_i->forwarding->i)
614
615 The ``__weak`` variable is stored in a ``_block_byref_foo`` structure and the
616 ``Block`` has copy and dispose helpers for this structure that call:
617
618 .. code-block:: c
619
620     _Block_object_assign(&dest->_block_byref_i, src-> _block_byref_i, BLOCK_FIELD_IS_WEAK | BLOCK_FIELD_IS_BYREF);
621
622 and:
623
624 .. code-block:: c
625
626     _Block_object_dispose(src->_block_byref_i, BLOCK_FIELD_IS_WEAK | BLOCK_FIELD_IS_BYREF);
627
628 In turn, the ``block_byref`` copy support helpers distinguish between whether
629 the ``__block`` variable is a ``Block`` or not and should either call:
630
631 .. code-block:: c
632
633     _Block_object_assign(&dest->_block_byref_i, src->_block_byref_i, BLOCK_FIELD_IS_WEAK | BLOCK_FIELD_IS_OBJECT | BLOCK_BYREF_CALLER);
634
635 for something declared as an object or:
636
637 .. code-block:: c
638
639     _Block_object_assign(&dest->_block_byref_i, src->_block_byref_i, BLOCK_FIELD_IS_WEAK | BLOCK_FIELD_IS_BLOCK | BLOCK_BYREF_CALLER);
640
641 for something declared as a ``Block``.
642
643 A full example follows:
644
645 .. code-block:: c
646
647     __block __weak id obj = <initialization expression>;
648     functioncall(^{ [obj somemessage]; });
649
650 would translate to:
651
652 .. code-block:: c
653
654     struct _block_byref_obj {
655         void *isa;  // uninitialized
656         struct _block_byref_obj *forwarding;
657         int flags;   //refcount;
658         int size;
659         void (*byref_keep)(struct _block_byref_i *dst, struct _block_byref_i *src);
660         void (*byref_dispose)(struct _block_byref_i *);
661         id captured_obj;
662     };
663
664     void _block_byref_obj_keep(struct _block_byref_voidBlock *dst, struct _block_byref_voidBlock *src) {
665         //_Block_copy_assign(&dst->captured_obj, src->captured_obj, 0);
666         _Block_object_assign(&dst->captured_obj, src->captured_obj, BLOCK_FIELD_IS_OBJECT | BLOCK_FIELD_IS_WEAK | BLOCK_BYREF_CALLER);
667     }
668
669     void _block_byref_obj_dispose(struct _block_byref_voidBlock *param) {
670         //_Block_destroy(param->captured_obj, 0);
671         _Block_object_dispose(param->captured_obj, BLOCK_FIELD_IS_OBJECT | BLOCK_FIELD_IS_WEAK | BLOCK_BYREF_CALLER);
672     };
673
674 for the block ``byref`` part and:
675
676 .. code-block:: c
677
678     struct __block_literal_5 {
679         void *isa;
680         int flags;
681         int reserved;
682         void (*invoke)(struct __block_literal_5 *);
683         struct __block_descriptor_5 *descriptor;
684         struct _block_byref_obj *byref_obj;
685     };
686
687     void __block_invoke_5(struct __block_literal_5 *_block) {
688        [objc_read_weak(&_block->byref_obj->forwarding->captured_obj) somemessage];
689     }
690
691     void __block_copy_5(struct __block_literal_5 *dst, struct __block_literal_5 *src) {
692          //_Block_byref_assign_copy(&dst->byref_obj, src->byref_obj);
693          _Block_object_assign(&dst->byref_obj, src->byref_obj, BLOCK_FIELD_IS_BYREF | BLOCK_FIELD_IS_WEAK);
694     }
695
696     void __block_dispose_5(struct __block_literal_5 *src) {
697          //_Block_byref_release(src->byref_obj);
698          _Block_object_dispose(src->byref_obj, BLOCK_FIELD_IS_BYREF | BLOCK_FIELD_IS_WEAK);
699     }
700
701     static struct __block_descriptor_5 {
702         unsigned long int reserved;
703         unsigned long int Block_size;
704         void (*copy_helper)(struct __block_literal_5 *dst, struct __block_literal_5 *src);
705         void (*dispose_helper)(struct __block_literal_5 *);
706     } __block_descriptor_5 = { 0, sizeof(struct __block_literal_5), __block_copy_5, __block_dispose_5 };
707
708 and within the compound statement:
709
710 .. code-block:: c
711
712     truct _block_byref_obj obj = {( .forwarding=&obj, .flags=(1<<25), .size=sizeof(struct _block_byref_obj),
713                      .byref_keep=_block_byref_obj_keep, .byref_dispose=_block_byref_obj_dispose,
714                      .captured_obj = <initialization expression> )};
715
716     truct __block_literal_5 _block_literal = {
717          &_NSConcreteStackBlock,
718          (1<<25)|(1<<29), <uninitialized>,
719          __block_invoke_5,
720          &__block_descriptor_5,
721          &obj,        // a reference to the on-stack structure containing "captured_obj"
722     };
723
724
725     functioncall(_block_literal->invoke(&_block_literal));
726
727 C++ Support
728 ===========
729
730 Within a block stack based C++ objects are copied into ``const`` copies using
731 the copy constructor.  It is an error if a stack based C++ object is used within
732 a block if it does not have a copy constructor.  In addition both copy and
733 destroy helper routines must be synthesized for the block to support the
734 ``Block_copy()`` operation, and the flags work marked with the (1<<26) bit in
735 addition to the (1<<25) bit.  The copy helper should call the constructor using
736 appropriate offsets of the variable within the supplied stack based block source
737 and heap based destination for all ``const`` constructed copies, and similarly
738 should call the destructor in the destroy routine.
739
740 As an example, suppose a C++ class ``FOO`` existed with a copy constructor.
741 Within a code block a stack version of a ``FOO`` object is declared and used
742 within a ``Block`` literal expression:
743
744 .. code-block:: c++
745
746     {
747         FOO foo;
748         void (^block)(void) = ^{ printf("%d\n", foo.value()); };
749     }
750
751 The compiler would synthesize:
752
753 .. code-block:: c++
754
755     struct __block_literal_10 {
756         void *isa;
757         int flags;
758         int reserved;
759         void (*invoke)(struct __block_literal_10 *);
760         struct __block_descriptor_10 *descriptor;
761         const FOO foo;
762     };
763
764     void __block_invoke_10(struct __block_literal_10 *_block) {
765        printf("%d\n", _block->foo.value());
766     }
767
768     void __block_copy_10(struct __block_literal_10 *dst, struct __block_literal_10 *src) {
769          FOO_ctor(&dst->foo, &src->foo);
770     }
771
772     void __block_dispose_10(struct __block_literal_10 *src) {
773          FOO_dtor(&src->foo);
774     }
775
776     static struct __block_descriptor_10 {
777         unsigned long int reserved;
778         unsigned long int Block_size;
779         void (*copy_helper)(struct __block_literal_10 *dst, struct __block_literal_10 *src);
780         void (*dispose_helper)(struct __block_literal_10 *);
781     } __block_descriptor_10 = { 0, sizeof(struct __block_literal_10), __block_copy_10, __block_dispose_10 };
782
783 and the code would be:
784
785 .. code-block:: c++
786
787     {
788       FOO foo;
789       comp_ctor(&foo); // default constructor
790       struct __block_literal_10 _block_literal = {
791         &_NSConcreteStackBlock,
792         (1<<25)|(1<<26)|(1<<29), <uninitialized>,
793         __block_invoke_10,
794         &__block_descriptor_10,
795        };
796        comp_ctor(&_block_literal->foo, &foo);  // const copy into stack version
797        struct __block_literal_10 &block = &_block_literal;  // assign literal to block variable
798        block->invoke(block);    // invoke block
799        comp_dtor(&_block_literal->foo); // destroy stack version of const block copy
800        comp_dtor(&foo); // destroy original version
801     }
802
803
804 C++ objects stored in ``__block`` storage start out on the stack in a
805 ``block_byref`` data structure as do other variables.  Such objects (if not
806 ``const`` objects) must support a regular copy constructor.  The ``block_byref``
807 data structure will have copy and destroy helper routines synthesized by the
808 compiler.  The copy helper will have code created to perform the copy
809 constructor based on the initial stack ``block_byref`` data structure, and will
810 also set the (1<<26) bit in addition to the (1<<25) bit.  The destroy helper
811 will have code to do the destructor on the object stored within the supplied
812 ``block_byref`` heap data structure.  For example,
813
814 .. code-block:: c++
815
816     __block FOO blockStorageFoo;
817
818 requires the normal constructor for the embedded ``blockStorageFoo`` object:
819
820 .. code-block:: c++
821
822     FOO_ctor(& _block_byref_blockStorageFoo->blockStorageFoo);
823
824 and at scope termination the destructor:
825
826 .. code-block:: c++
827
828     FOO_dtor(& _block_byref_blockStorageFoo->blockStorageFoo);
829
830 Note that the forwarding indirection is *NOT* used.
831
832 The compiler would need to generate (if used from a block literal) the following
833 copy/dispose helpers:
834
835 .. code-block:: c++
836
837     void _block_byref_obj_keep(struct _block_byref_blockStorageFoo *dst, struct _block_byref_blockStorageFoo *src) {
838          FOO_ctor(&dst->blockStorageFoo, &src->blockStorageFoo);
839     }
840
841     void _block_byref_obj_dispose(struct _block_byref_blockStorageFoo *src) {
842          FOO_dtor(&src->blockStorageFoo);
843     }
844
845 for the appropriately named constructor and destructor for the class/struct
846 ``FOO``.
847
848 To support member variable and function access the compiler will synthesize a
849 ``const`` pointer to a block version of the ``this`` pointer.
850
851 .. _RuntimeHelperFunctions:
852
853 Runtime Helper Functions
854 ========================
855
856 The runtime helper functions are described in
857 ``/usr/local/include/Block_private.h``.  To summarize their use, a ``Block``
858 requires copy/dispose helpers if it imports any block variables, ``__block``
859 storage variables, ``__attribute__((NSObject))`` variables, or C++ ``const``
860 copied objects with constructor/destructors.  The (1<<26) bit is set and
861 functions are generated.
862
863 The block copy helper function should, for each of the variables of the type
864 mentioned above, call:
865
866 .. code-block:: c
867
868      _Block_object_assign(&dst->target, src->target, BLOCK_FIELD_<apropos>);
869
870 in the copy helper and:
871
872 .. code-block:: c
873
874     _Block_object_dispose(->target, BLOCK_FIELD_<apropos>);
875
876 in the dispose helper where ``<apropos>`` is:
877
878 .. code-block:: c
879
880     enum {
881         BLOCK_FIELD_IS_OBJECT   =  3,  // id, NSObject, __attribute__((NSObject)), block, ...
882         BLOCK_FIELD_IS_BLOCK    =  7,  // a block variable
883         BLOCK_FIELD_IS_BYREF    =  8,  // the on stack structure holding the __block variable
884
885         BLOCK_FIELD_IS_WEAK     = 16,  // declared __weak
886
887         BLOCK_BYREF_CALLER      = 128, // called from byref copy/dispose helpers
888     };
889
890 and of course the constructors/destructors for ``const`` copied C++ objects.
891
892 The ``block_byref`` data structure similarly requires copy/dispose helpers for
893 block variables, ``__attribute__((NSObject))`` variables, or C++ ``const``
894 copied objects with constructor/destructors, and again the (1<<26) bit is set
895 and functions are generated in the same manner.
896
897 Under ObjC we allow ``__weak`` as an attribute on ``__block`` variables, and
898 this causes the addition of ``BLOCK_FIELD_IS_WEAK`` orred onto the
899 ``BLOCK_FIELD_IS_BYREF`` flag when copying the ``block_byref`` structure in the
900 ``Block`` copy helper, and onto the ``BLOCK_FIELD_<apropos>`` field within the
901 ``block_byref`` copy/dispose helper calls.
902
903 The prototypes, and summary, of the helper functions are:
904
905 .. code-block:: c
906
907     /* Certain field types require runtime assistance when being copied to the
908        heap.  The following function is used to copy fields of types: blocks,
909        pointers to byref structures, and objects (including
910        __attribute__((NSObject)) pointers.  BLOCK_FIELD_IS_WEAK is orthogonal to
911        the other choices which are mutually exclusive.  Only in a Block copy
912        helper will one see BLOCK_FIELD_IS_BYREF.
913     */
914     void _Block_object_assign(void *destAddr, const void *object, const int flags);
915
916     /* Similarly a compiler generated dispose helper needs to call back for each
917        field of the byref data structure.  (Currently the implementation only
918        packs one field into the byref structure but in principle there could be
919        more).  The same flags used in the copy helper should be used for each
920        call generated to this function:
921     */
922     void _Block_object_dispose(const void *object, const int flags);
923
924 Copyright
925 =========
926
927 Copyright 2008-2010 Apple, Inc.
928 Permission is hereby granted, free of charge, to any person obtaining a copy
929 of this software and associated documentation files (the "Software"), to deal
930 in the Software without restriction, including without limitation the rights
931 to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
932 copies of the Software, and to permit persons to whom the Software is
933 furnished to do so, subject to the following conditions:
934
935 The above copyright notice and this permission notice shall be included in
936 all copies or substantial portions of the Software.
937
938 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
939 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
940 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
941 AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
942 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
943 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
944 THE SOFTWARE.