rust::Str and rust::String not being null terminated is not obvious

[TheZoq2]

First of all, thanks for this great library, with very little effort, it allows me to write a nice rust frontend fro my c++ project.

When I started using it to pass some strings from the rust side, I quickly found the Builtin types table, and given that a data function is available on rust::Str, I assumed that it would be fine to copy the content using std::string(rust_string.data()). Obviously this turned out to not be the case, but I don't think that's clear, at least from the parts of the documentation that I have read.

Would it be a good idea to put an entry in the "restrictions" column saying that this is the case?

[dtolnay]

The intended reference for the API of the C++ types is the header: https://github.com/dtolnay/cxx/blob/0.3.4/include/cxx.h (for now; at least until #179 is closed). This is probably where you found the data function.

The header has a comment on Str::data and String::data indicating that there is no null terminator:

cxx/include/cxx.h

Lines 37 to 38 in bbd2620

	// Note: no null terminator.
	const char *data() const noexcept;

cxx/include/cxx.h

Lines 66 to 67 in bbd2620

	// Note: no null terminator.
	const char *data() const noexcept;

[TheZoq2]

This is probably where you found the data function.

Not quite, I did find it when noticing a problem with the strings, but I initially found it using my editor autocomplete, so I never saw the comment. I guess this issue is mostly a "I read the bare minimum amount of docs and got surprised when things went wrong :)"

[KamilaBorowska]

rust::Str is kinda like std::string_view (minus encoding considerations which is why those are distinct types) which is not guaranteed to be null terminated.

[cgwalters]

I'm actually converting a C codebase to "compile in C++ mode" purely so I can use this project. And starting from a world where NUL terminated C strings are pervasive then adding C++ std::string and Rust String is very painful so far (basically need to do auto s = std::string(rustobject->getstring()); some_c_function(s.c_str()).

In some cases on the Rust side we've been using https://crates.io/crates/c_utf8 (which...IMO should probably be part of Rust std but that's a whole other discussion). Using that one can avoid a copy. Perhaps this crate could have a feature gate to enable adding that as a binding?

[dtolnay]

How about adding a c_str() member function for rust::String? #586