Re: [PATCH 4/7] xdiff: make fields of xrecord_t Rust friendly

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

 



On Thu, Jul 17, 2025 at 04:37:24PM -0700, Elijah Newren wrote:
> > However, I'm not dead set against casting in Rust if that's what
> > everyone else wants instead.
>
> In general, I too would prefer to do the casting on the C side; after
> all, part of the reason for Rust is the language safety, which we
> compromise if we force it into using ambiguously sized variables.
>
> However, I think it might be somewhat case-dependent...
>
> Here, we have C calling into APIs that will be defined and implemented
> in Rust.  Further along the road of adopting Rust in more places, we
> may have future cases where we have Rust calling into APIs defined and
> implemented in C.  I'm wondering if in such a world the rule of thumb
> that makes the most sense would be to have a
> caller-must-cast-as-necessary guideline, rather than specifying the
> casting side by language.

Yeah, I think having some sort of general guidance here spelled out in
CodingGuidelines would be helpful. I don't think that it needs to
prescribe a specific rule, but having some of what you and brian wrote
above captured more permanently would give contributors more information
about why they may want to place the casts on one side versus the other.

Thanks,
Taylor




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux