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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 27, 2022 at 01:06:28PM +0200, Miguel Ojeda wrote:
> On Wed, Jul 27, 2022 at 12:08 PM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> >
> > It should never return NULL.  At the moment.
> > I would prefer to have NULL checks for all cases, not assume anything
> > about the C implementation, and to be consistent with other places
> > where you do NULL checks.  As it stands when I see this I need to go check
> > the C to see if this is a reasonable exception or not.  And I'm lazy.
> 
> Ideally the C side would document the guarantees explicitly instead,
> and then the Rust side can rely on them.
> 

Unfortunately the C header doesn't currently provide any guarantee -
except in the cases where it CAN return NULL.
But we can fix that.

> In any case, if a given C API never returned an invalid pointer and
> suddenly it starts doing so in some cases, I would consider that a
> breaking change in practice, which would likely break 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.

> A potential compromise meanwhile is `debug_assert!` to at least test
> those assumptions.
> 

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.

Cheers,
Kent.



[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux