not sure how this can work w/o creating other struct;

That's actually easy if the returned data types are simple enough:

// Callable from C
// The caller is only allowed to pass a valid pointer obtained by INSERT_SOME_OTHER_FN
// Returned pointer always points at the beginning of 32 byte-long array
// The returned pointer is never NULL
pub extern "C" fn outpoint_txid(this: *const Self) -> *const u8 {
    unsafe {
        (*this).txid.as_ptr()
    }
}

A nice thing about this approach is it could actually allow access to non-repr(C) fields. For instance returning a pointer to contents of Vec is possible if the items are primitive.

Note that repr(C) will deactivate Rust-specific optimizations such as reordering of the fields. To keep them, they need to be implemented manually before adding repr(C). This will also prevent any optimizations that would appear in the future.

I think it's much nicer to not add repr(C) and instead create a separate API for C. This APi will be stable but not guaranteed to be as efficient as if written in Rust.

Not an expert on LTO, so IDK if it removing conversion @TheBlueMatt suggests is realistic but if someone cares about copying a few bytes perhaps it'd be more sensible to write such performance-sensitive code in Rust in the first place. Also, would be nice if the auto-generator could optimize those repr(C) structs.

Doing #[repr(C)] for the main data structs #534

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Doing `#[repr(C)]` for the main data structs #534