arcnmx / cstrptr-rs Goto Github PK

Is this unsound or simply erroneous? It at least seems very unlikely to happen by accident.

Fix this by turning it into a proc macro, or if recursive const fn/generics ever become a thing that could work too.

this should probably be:

Self::from_bytes_with_nul_unchecked(core::slice::from_raw_parts(ptr as *const _, len + 1))

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.

Track and fix any API differences for including missing types, functions, etc.

• std::ffi::NulError (and probably other error types?)
• lots more!