Implement `CStr` as a pointer rather than a slice

[czipperz]

Littered throughout the CStr documentation are notes and hints that it should be eventually converted to using a pointer underneath the hood instead of a slice. This change will make CStr::from_ptr O(1) instead of O(n). Other constructors may still be O(n) because they have to check to ensure there is only one null terminator. If someone wants to try implementing this, it seems like a pretty simple change.

Current struct definition:

pub struct CStr {
    inner: [c_char]
}

Proposed:

pub struct CStr {
    inner: *const c_char
}

[czipperz]

I'm not sure if this needs an RFC. If so I can make it.

[czipperz]

Potential complications: CStr must remain !Sized. Is there a way to explicitly mark a struct as not Sized?
Can it just impl !Sized for CStr {}

[czipperz]

The current definition makes &CStr roughly equivalent to *const c_char, whereas the proposed new definition would have another layer of indirection. That is, we want CStr to be the actual bytes in the string. So really we shouldn't be storing a pointer, but rather an unsized slice.

[czipperz]

Perhaps we do something like

pub struct CStr {
    inner: [c_char; 1],
    _marker: PhantomUnsized
}

But that would require PhantomUnsized to exist.

[Kampfkarren]

_marker: [PhantomData<()>]?

[LifeIsStrange]

This seems to be prior art: https://github.com/kennytm/thin_cstr
@kennytm

[czipperz]

Thanks @LifeIsStrange . I couldn't find an open issue for this so I'll keep it open

[LifeIsStrange]

here are the blockers (custom DST support) kennytm/thin_cstr#1

[lambda-fairy]

Is it worth adding a link in the documentation to this issue? So that future readers know where to look.

[RalfJung]

pub struct CStr {
    inner: [c_char]
}

Proposed:

pub struct CStr {
    inner: *const c_char
}

This seems wrong. CStr is defined with the intention that *mut CStr is like char* in C. Your proposed CStr has one pointer indirection too many.

Proper CStr is blocked on custom DSTs, AFAIK.

[czipperz]

@RalfJung I already noted it above. It's a good point though and an interesting design decision