Objc block invoke foreign

[TotallyGamerJet]

What issue is this addressing?

Closes #536

What type of issue is this addressing?

bug

What this PR does | solves

This PR allows calling objc.Block with blocks that were created from other sources

[hajimehoshi]

Invoke crashes on a foreign block that returns a struct in memory.

The foreign path in Invoke calls callForeign(nil, args), which declares no result:

purego/objc/objc_block_darwin.go

Lines 258 to 261 in 9be702e

	if !fn.IsValid() {
	b.callForeign(nil, args)
	return
	}

When the block's C return type is a struct returned in memory (larger than 16 bytes), the caller has to pass a hidden pointer to the result buffer. No such pointer is passed here. On darwin/arm64 the block writes its result through whatever happens to be in x8. By the amd64 ABI (not tested) the block would take rdi, which holds the block pointer, as the result buffer. It would overwrite the block's isa/flags/invoke and read every argument shifted by one register.

Repro on darwin/arm64, added to testdata/block.m:

typedef struct { int64_t a, b, c, d; } Big;
void *purego_big_block(void) {
    Big (^b)(int64_t) = ^Big(int64_t x) { Big r = {x, x, x, x}; return r; };
    return Block_copy(b);
}

lib := loadBlockFixture(t)
var bigBlock func() objc.Block
purego.RegisterLibFunc(&bigBlock, lib, "purego_big_block")
block := bigBlock()
block.Invoke(int64(1)) // SIGSEGV

BLOCK_USE_STRET (1 << 29) can't guard this: it is not set on this block (flags = 0x50000000). BLOCK_HAS_SIGNATURE is set, though. The descriptor's type encoding gives the real return type, so Invoke could allocate the result or refuse the call. Note that the signature's offset in the descriptor depends on BLOCK_HAS_COPY_DISPOSE.

---

Filed by Claude (Claude Code), on behalf of @hajimehoshi.

[hajimehoshi]

Did we support structs for blocks btw?

[hajimehoshi]

A blank padding field such as _ [3]byte has a non-zero size, so it ends up in the layout string. The C encoding has no entry for padding, so the two sides never match. RegisterFunc's docs tell callers to add struct padding themselves, and purego's own struct tests do exactly that:

purego/func.go

Lines 104 to 106 in 87dc024

	// Purego can handle the most common structs that have fields of builtin types like int8, uint16, float32, etc. However,
	// it does not support aligning fields properly. It is therefore the responsibility of the caller to ensure
	// that all padding is added to the Go struct to match the C one. See `BoolStructFn` in struct_test.go for an example.

purego/struct_test.go

Lines 613 to 618 in 87dc024

	type BoolFloat struct {
	_ structs.HostLayout
	b bool
	_ [3]byte // purego won't do padding for you so make sure it aligns properly with C struct
	f float32
	}

A Go mirror written that way is refused even though its layout matches C:

type BoolFloat struct {
	_ structs.HostLayout
	b bool
	_ [3]byte
	f float32
}

goABI returns {1111f} for this type, but encodingABI("{BoolFloat=Bf}") returns {1f}. So InvokeBlock[BoolFloat] gives a mismatch error for a block that returns struct { bool b; float f; }.

Skipping blank fields isn't enough on its own, because a _ int32 can also stand in for a real C field the caller doesn't need. Treating blank fields as opaque bytes would handle both cases: require the same total size, and require every C field to either line up with a named Go field of the same kind at the same offset, or fall inside a blank Go field. The C offsets come from the encoding with natural alignment.

Filed by Claude (Claude Code), on behalf of @hajimehoshi.