[taping-memory]

I'm reading the article and so far it's great.

I'm just wondering in the explanation of listing 2 you say:

> a discriminant value indicating the enum’s active variant (4 bytes)

As far as I can find, there's no guarantee for that, the only thing I can find is that it might be interpreted as an `isize` value but the compiler is permitted to use smaller values: https://doc.rust-lang.org/reference/items/enumerations.html#...

Is there any reason to say it should be 4 bytes?

It doesn't change any of the conclusions, I'm just curious

[OptionOfT]

Using repr(C) makes it 4 bytes.

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.

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.

[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.