From: "Erik Schilling" <erik.schilling@linaro.org>
To: "Bartosz Golaszewski" <brgl@bgdev.pl>
Cc: <linux-gpio@vger.kernel.org>,
"Bartosz Golaszewski" <bartosz.golaszewski@linaro.org>,
"Kent Gibson" <warthog618@gmail.com>,
"Linus Walleij" <linus.walleij@linaro.org>,
"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
"Viresh Kumar" <viresh.kumar@linaro.org>
Subject: Re: [libgpiod][PATCH 5/5] bindings: rust: provide LineRequest::chip_path()
Date: Thu, 20 Jul 2023 07:04:00 +0200 [thread overview]
Message-ID: <CU6QJJUDI5D7.2GPPMGLBM6C83@fedora> (raw)
In-Reply-To: <20230719192057.172560-6-brgl@bgdev.pl>
On Wed Jul 19, 2023 at 9:20 PM CEST, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> Provide a wrapper around gpiod_line_request_get_chip_path() for Rust
> bindings and add a test-case.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> ---
[...]
> diff --git a/bindings/rust/libgpiod/src/line_request.rs b/bindings/rust/libgpiod/src/line_request.rs
> index 1140aa9..2caab14 100644
> --- a/bindings/rust/libgpiod/src/line_request.rs
> +++ b/bindings/rust/libgpiod/src/line_request.rs
[...]
> @@ -25,6 +26,17 @@ impl Request {
> Ok(Self { request })
> }
>
> + pub fn chip_path(&self) -> Result<&str> {
A rustdoc comment `/// <explanation>` on the function may be helpful.
The other functions have some (though those could probably also be a
little longer...).
More importantly, _if_ this function is returning a file path, then I
would consider to return a Path [1]. The conversion from &str -> Path is
"0-cost" and makes the API more explicit. `Sim::dev_path()` also returns
a PathBuf so the conversion in the test would become a little easier.
> + // SAFETY: The string returned by libgpiod is guaranteed to live as long
> + // as the `struct LineRequest`.
> + let path = unsafe { gpiod::gpiod_line_request_get_chip_path(self.request) };
The SAFETY comment should explain why the following `unsafe` block is
safe. For this block, the lifetime of the string does not matter for
safety. Instead, it should explain why self.request is valid and safe
to use.
Maybe like this?
+ // SAFETY: The `gpiod_line_request` is guaranteed to be live as long
+ // as `&self`
> + // SAFETY: The string is guaranteed to be valid here by the C API.
> + unsafe { CStr::from_ptr(path) }
> + .to_str()
> + .map_err(Error::StringNotUtf8)
> + }
Here the lifetime of the string is important then! Checking the
Cstr::from_ptr doc [2], one needs to ensure that:
- The memory pointed to by ptr must contain a valid nul terminator at
the end of the string.
- ptr must be valid for reads of bytes up to and including the null
terminator.
- The memory referenced by the returned CStr must not be mutated for the
duration of lifetime 'a.
The SAFETY comment should explain why these three requirements are
satisfied.
Suggestion:
+ // SAFETY: The string is guaranteed to be valid, non-null and immutable
+ // by the C API for the lifetime of the `gpiod_line_request`. The
+ // `gpiod_line_request` is living as long as `&self`. The string is
+ // returned read-only with a lifetime of `&self`.
[1] https://doc.rust-lang.org/stable/std/path/struct.Path.html
[2] https://doc.rust-lang.org/std/ffi/struct.CStr.html#method.from_ptr
[...]
LGTM otherwise.
- Erik
next prev parent reply other threads:[~2023-07-20 5:04 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-19 19:20 [libgpiod][PATCH 0/5] core: provide information about the parent chip in line requests Bartosz Golaszewski
2023-07-19 19:20 ` [libgpiod][PATCH 1/5] core: provide gpiod_line_request_get_chip_path() Bartosz Golaszewski
2023-07-19 19:20 ` [libgpiod][PATCH 2/5] tests: add a test-case for gpiod_line_request_get_chip_path() Bartosz Golaszewski
2023-07-19 19:20 ` [libgpiod][PATCH 3/5] bindings: cxx: provide line_request::chip_path() Bartosz Golaszewski
2023-07-19 19:20 ` [libgpiod][PATCH 4/5] bindings: python: provide the chip_path property in line_request Bartosz Golaszewski
2023-07-19 19:20 ` [libgpiod][PATCH 5/5] bindings: rust: provide LineRequest::chip_path() Bartosz Golaszewski
2023-07-20 5:04 ` Erik Schilling [this message]
2023-07-20 8:04 ` Bartosz Golaszewski
2023-07-20 8:10 ` Erik Schilling
2023-07-20 3:27 ` [libgpiod][PATCH 0/5] core: provide information about the parent chip in line requests Kent Gibson
2023-07-20 7:59 ` Bartosz Golaszewski
2023-07-20 8:05 ` Kent Gibson
2023-07-20 8:25 ` Bartosz Golaszewski
2023-07-20 8:39 ` Kent Gibson
2023-07-20 8:49 ` Bartosz Golaszewski
2023-07-20 9:16 ` Kent Gibson
2023-07-20 9:38 ` Bartosz Golaszewski
2023-07-20 9:52 ` Kent Gibson
2023-07-20 12:30 ` Bartosz Golaszewski
2023-07-20 13:37 ` Kent Gibson
2023-07-20 15:01 ` Bartosz Golaszewski
2023-07-21 1:37 ` Kent Gibson
2023-07-20 8:42 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CU6QJJUDI5D7.2GPPMGLBM6C83@fedora \
--to=erik.schilling@linaro.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bartosz.golaszewski@linaro.org \
--cc=brgl@bgdev.pl \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=viresh.kumar@linaro.org \
--cc=warthog618@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).