Hacker News Reader

Comment by petabyt | Hacker News Reader

The most painful thing about this is strings. To convert to/from cstrings, you have to use the stdlib FFI function, which will allocate memory. This was a nice surprise in the form of a bunch of undefined GNU ABI references when linking to C. I was writing bare metal firmware. I hadn't imported libgcc or even libc yet. Having to convert every string and use unsafe blocks everywhere is a pain. And last time I tried it wasn't even possible to interface with a varargs function. Im not a big Zig fan but it looks so much better from a FFI perspective. I haven't tried it but it looks like everything just works.

View on HN

> And last time I tried it wasn't even possible to interface with a varargs function.

Calling varargs functions over FFI has been possible since before Rust 1.0, here's printf, for example https://docs.rs/libc/latest/libc/fn.printf.html

But you would have to manually pass cstrings into it? Is there a way to make a wrapper to pass rust strings into it? Now that I think about it that may have been my issue.

Correct, Rust and C strings are different, so you have to do some sort of conversion between the two, if you have a String and want to pass a *const c_char.

For going from C to Rust, I think you'd just use CString::to_str instead of CString::to_string. I'm pretty sure this just calls std::transmute behind the scenes and doesn't cause an allocation. (In the same way that you generally don't clone vanilla strings and instead pass references around.) iirc, it's still tricky to go the other way. I think if I was working with super C-FFI heavy code, I'd just end up using CString as my default for that code. Custom allocators would also help there, since you could just create the strings on the stack or whatever, but I don't remember if the string version of those is even finished in nightly yet.

You'd use CStr::from_ptr if you've received a C string (which does not allocate, that's correct, though not via transmute, just a cast), but since Rust strings aren't null terminated, you'll need to allocate some memory to add the null byte on the end. Which yeah, then I'd want to try to use CString as much as possible, in that case.

(If you wrote to an array on the stack, you could turn it into a Cstr too, instead of heap allocating, but then you'd have a max string size, which may or may not be something you'd want.)

alloc::string::String (a.k.a. std::string::String) doesn't support custom allocators yet, even on nightly, but that doesn't mean you can't use them; it just means you have to use a third-party crate, like https://docs.rs/string or https://docs.rs/smol_str.

Reply on news.ycombinator.com