Re: [PATCH V4 4/8] libgpiod: Add rust wrapper crate

[Miguel Ojeda <miguel.ojeda.sandonis@xxxxxxxxx>]

On Wed, Jul 27, 2022 at 2:40 PM Kent Gibson <warthog618@xxxxxxxxx> wrote:
>
> Unfortunately the C header doesn't currently provide any guarantee -
> except in the cases where it CAN return NULL.
> But we can fix that.

Yeah, fixing that is what I was suggesting, since it is a possibility
here, and would improve things for C users too.

> Not sure I'm onboard with that.  Unless the API has a contract not to
> return a NULL then it is free to at a later date. The user should
> always assume that NULL is a possibility, even if they have never seen
> one.
>
> But in practice you are probably right.

I definitely agree that a client should aim to avoid assuming anything.

However, if we are strict, given C pointers are unconstrained, all
pointers would be useless unless told otherwise, because checking for
NULL is not a guarantee of validity either.

Also, if an C API just says "returns the name", for instance, it is
reasonable to assume it is a valid name because it is not said
otherwise (e.g. it does not say "returns the name, if available" nor
"returns an optional name").

And, of course, eventually consumers will end up relying on your
particular implementation no matter what, and returning invalid
pointers where there weren't before is a very dangerous idea for a C
library.

> I'd be fine with that.
> I'd also be satisfied with a comment in the Rust that the C guarantees a
> non-NULL where that is the case.  That would at least demonstrate that the
> possibility has been duly considered.

I think the current `SAFETY` comment already intends to imply that,
but yeah, it could be clarified.

In any case, I would say it always returns a valid pointer, not
"non-NULL", since the latter does not really show it is a valid
pointer (it could point to a non-NULL, bad address).

Cheers,
Miguel