Error representation

[Diggsey]

Kernel error numbers are non-zero and positive, so I was wondering if it would make sense to constrain the Error type in that way (making the from c_int conversion fallible).

It could use the NonZero wrapper for now, and in the future might be able to have a niche for negative numbers as well. This would allow a return type of KernelResult<()> to be exactly equivalent to c_int.

[jabedude]

Would this prevent rust code from following the kernel's negative return value convention? (like -ENOMEM, etc)

[alex]

When interfacing with existing C code, we follow those APIs at the boundaries, but interlaly we represent things with Rust's Result type -- an then we convert to an int as required.

…

On Thu, Apr 15, 2021 at 3:30 PM Josh Abraham ***@***.***> wrote: Would this prevent rust code from following the kernel's negative return value convention? (like -ENOMEM, etc) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#195 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBCVPDGXVUR5G5IGI5LTI45HDANCNFSM426GJXGQ> .

-- All that is necessary for evil to succeed is for good people to do nothing.

[matthiasbeyer]

I'm not sure I asked this before: Why isn't there a From<c_int> impl for Error? Because arbitrary integers could then be converted to an Error instance and that is actually not feasible?

[kornelski]

It's possible to add a bit of type safety and Rust-convenience to FFI functions that return integers as errors:

/// Newtype on int that makes it safe for use in FFI
#[repr(transparent)]
ZeroOnSuccess(c_int)

extern "C" {
   /// FFI definitions can type-safely document error handling convention
   fn may_return_int_on_error() -> ZeroOnSuccess;
}

/// The newtype can have helpers for checking it
impl ZeroOnSuccess {
   fn to_result(&self) -> Result<(), Error> {
      if self.0 == 0 {
        Ok(())
      } else {
        …
      }
   }
}

may_return_int_on_error().to_result()?;