[taping-memory]

> Using repr(C) makes it 4 bytes.

That makes sense, they just don't use repr(C) for the PrintResult so I didn't consider that.

> But then again, modeling a C enum to a Rust enum is bad design. You want to use const in Rust and match against those.

That makes sense but if there could be a way to safely generate code that converts to an enum safely as proposed in the article that would be good as the enum is more idiomatic.

> But it is a bad example in general, because the author passes on a pointer of a string slice to FFI without first converting it to a CString, so it isn't null terminated.

The signature for async_print in C is `async_res_t async_print(const *uint8_t, size_t)` and they are passing a pointer to a &[u8] created from a byte string literal, so I think it's correct.