4 ms·

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

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#r-items.enum.discriminant.repr-rust 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 1y ago
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 1y ago
  > 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.

4 ms·

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

by taping-memory 1y ago

OptionOfT 1y ago
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 1y ago
  > 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.