At least SharedMemRaw::create(), ::open() internally just takes a reference of the string, so could use a &str instead (to allow no allocations).
Similarly SharedMemConf::set_link_path() takes &PathBuf and that could just be a &Path for the same reason, and the same in SharedMem::create_linked() and SharedMem::open_linked().
Relatedly, get_link_path() and get_os_path() and similar should probably return references to the unowned types (str, Path) instead.
And it seems that the OS path related API should actually use OsStr / OsString instead, AFAIU it might not be a valid UTF8 string (on UNIX systems at least).
At least
SharedMemRaw::create()
,::open()
internally just takes a reference of the string, so could use a&str
instead (to allow no allocations).Similarly
SharedMemConf::set_link_path()
takes&PathBuf
and that could just be a&Path
for the same reason, and the same inSharedMem::create_linked()
andSharedMem::open_linked()
.Relatedly,
get_link_path()
andget_os_path()
and similar should probably return references to the unowned types (str
,Path
) instead.And it seems that the OS path related API should actually use
OsStr
/OsString
instead, AFAIU it might not be a valid UTF8 string (on UNIX systems at least).