A future where &CStr is fixed

[arcnmx]

This library intends to paper over the undefined representation of CStr by offering both versions and guaranteeing their performance/storage characteristics. It also re-exports std types when that feature is used. If &CStr is ever fixed to be a single pointer (and thus becomes equivalent to CStrPtr) then the types this crate exports for std need to accommodate that by re-exporting std::ffi::CStr as CStrPtr. It would then offer a custom &CStr pointer implementing the old behaviour.

rustversion would be good to use when the time comes? However, consider that CStrPtr doesn't currently exist due to custom DSTs not being usable, which means that offering &CStrPtr instead of CStrPtr<'_> will require a newer rustc anyway. I suppose a third type name will need to be decided on?

• &FatCStr
• &CStr
• CStrPtr

This naming change could (and maybe should) happen sooner rather than later, then simply do not have &CStr until there's a good way to create it. See also prior art using extern { type c_char; }, and the rustc tracking issue.