Smithay / udev-rs

Libudev bindings for Rust

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

util::errno_to_result incorrectly handles udev functions errors.

devcexx opened this issue · comments

According to the systemd 247 manpages (this, this, this, this and this), all the functions whose errors are currently being handled using the util::errno_to_result function might return both zero and positive values to indicate that the operation was successful. More specifically, in the manpages, we can read:

RETURN VALUE
       On success, [...] return an integer greater than, or
       equal to, 0.

However, the current implementation of util::errno_to_result is incorrectly assuming that the value zero is the only possible value that means that the operation has been completed successfully.

In my specific case, I've found an issue building a udev monitor using this library, because I was getting a panic when calling MonitorBuilder::match_tag, because the underlying call to udev_monitor_filter_add_match_tag was returning 1 instead of 0. However, the operation of adding this filter is successfully performed and, in fact, the monitor works flawlessly when updating the mentioned error detection condition.

So, I'd suggest to update the code of util::errno_to_result to match the specification of the functions from libudev.

Additionally, if the function can raise an error, it will return a negative value indicating the cause of the error, as stand their manpages. However, this value, in util::errno_to_result, is not being negated before passing it to std::io::Error:from_raw_os_error, so this function always return information about an unknown error. For example, if a EINVAL error occurs (error code 22), the panic I get from unwrapping the result is something like:

thread 'main' panicked at 'called Result::unwrap()on anErr value: Os { code: -22, kind: Other, message: "Unknown error -22" }', src/main.rs:45:54

... because from_raw_os_error should had received 22 instead of -22. If the error code is negated, the error is correctly identified:

thread 'main' panicked at 'called Result::unwrap()on anErr value: Os { code: 22, kind: InvalidInput, message: "Invalid argument" }', src/main.rs:45:54

Thx for the detailed description. Fixed by 50847a5 and published as 0.6.1.