-
Notifications
You must be signed in to change notification settings - Fork 703
Description
I am thinking about adding another trait to represent string, the definition will be same as our NixPath
trait, and these 2 traits only differ in semantics, NixPath
is for path, this new trait is for string.
By adding this trait, we split "C string" (C does not have a string type, it is only a sequence of chars followed by a NUL) into 2 categories by semantics:
- path
- string
Currently, it will be used in 2 interfaces if added:
-
The
ident
argument ofopenlog()
on non-Linux systemsLines 45 to 47 in 0c40b8d
#[cfg(not(target_os = "linux"))] pub fn openlog<S: AsRef<OsStr> + ?Sized>( ident: Option<&S>, From man page:
The string pointed to by
ident
is prepended to every message, and is typically set to the program name. -
The
path
argument ofposix_spawnp()
Lines 396 to 397 in 0c40b8d
pub fn posix_spawnp<SA: AsRef<CStr>, SE: AsRef<CStr>>( path: &CStr, It is the name of the program that the spawned child process will execute
This argument should not be called
path
, I will rename it tofile
Alternative approaches
-
Just use the
NixPath
traitIt will definitely work, though it will feel weird semantically due to the
Path
in its name. Or maybe we can rename the trait to something likeNixCString
? -
Use
S: AsRef<OsStr>
openlog()
currently uses this approach, after converting it to&OsStr
we can useNixPath
under the hood, so it is convenient:<OsStr as NixPath>::with_nix_path(os_str.as_ref(), |c_str| { // do something with c_str });
The only flaw of this method IMHO is that users cannot use
&CStr
becauseCStr
is notAsRef<OsStr>
, but&CStr
should be allowed.