libproc-rs
libproc-rs copied to clipboard
pidpath() should return Result<PathBuf, String>
I feel like pidpath()
should return Result<PathBuf, String>
since a path is not required to be UTF8, no?
I'll take a look to see how it's currently converted to String. Would be a breaking API change for current users though....so maybe need a variant of the method....
For MacOS (Darwin):
The source here: https://opensource.apple.com/source/Libc/Libc-594.9.4/darwin/libproc.c is not exactly "replete with comments" about the type of string it writes into the buffer.
It calls __proc_info(2, pid, PROC_PIDPATHINFO, (uint64_t)0, buffer, buffersize);
I couldn't find the docs for that yet. Source is here: https://opensource.apple.com/source/xnu/xnu-792.13.8/bsd/kern/proc_info.c It looks like that ends up calling vn_getpath(), which I'm still trying to find...it's header only says:
/*!
@function vn_getpath
@abstract Construct the path to a vnode.
@discussion Paths to vnodes are not always straightforward: a file with multiple hard-links will have multiple pathnames,
and it is sometimes impossible to determine a vnode's full path. vn_getpath() will not enter the filesystem.
@param vp The vnode whose path to obtain.
@param pathbuf Destination for pathname; should be of size MAXPATHLEN
@param len Destination for length of resulting path string. Result will include NULL-terminator in count--that is, "len"
will be strlen(pathbuf) + 1.
@return 0 for success or an error code.
*/
I wonder if any/all of these strings in the Mach/Darwin kernel are UTF-8?
For Linux: I don't know, would have to investigate more.
Do you have knowledge of either/both OS to confirm the kernels can return buffers with non-UTF-8 strings for paths. If so, I'd have to create a PathBuf from the raw buffer I imagine.
I've just read two complete books on Mac OS X & iOS internals that covers BSD layer, Darwin, XNU, libSystem, libproc and the syscall wrappers - and annoyingly UTF and the nature of these strings returned in the buffers from syscals wasn't mentioned anywhere! :-(