Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change some function signature #10

Closed
Aya0wind opened this issue Oct 12, 2022 · 2 comments
Closed

Change some function signature #10

Aya0wind opened this issue Oct 12, 2022 · 2 comments

Comments

@Aya0wind
Copy link

Hi, I'm writing a C-FFI binding for this project, but i think some function signature is not reasonable enough.

Example

pub fn keygen(
    _pk: &KpAbePublicKey,
    _msk: &KpAbeMasterKey,
    _policy: &String,
    _language: PolicyLanguage,
) -> Result<KpAbeSecretKey, RabeError> 

the parameter _policy in this function is &String, but this function only need a immutable reference, i recommend use &str.
Similarly, in this function:

pub fn encrypt(
    _gk: &Aw11GlobalKey,
    _pks: &Vec<Aw11PublicKey>,
    _policy: &String,
    _language: PolicyLanguage,
    _plaintext: &[u8],
) -> Result<Aw11Ciphertext, RabeError> 

the type of _pks should be &[Aw11PublicKey] instead of &Vec<Aw11PublicKey>

Reason

  • I can construct a String from a *const c_char by let s = String::from_raw_parts(policy as *mut u8,len, len) during FFI calling.But, because this String not really own its memory, so we need a std::mem::forget(s) to make sure not free the memory passed by FFI calling.
  • If use &str, i can construct a slice from pointer directly and no need to care about memory.
  • Also, When i pass a array of pointer for &Vec<Aw11PublicKey>, i need to use Vec::from_raw_partsand not free the memory.
  • Not only in FFI, if i want to pass a let policy = "xxxxx", i also need to construct a String and pass it to function. But if the parameter is &str, i can pass policy directly.
  • And because String had impl trait Deref<str>, pass a &String to a &str is ok.
  • Similarly, use &Vec<T> instead of &[T] has the same problem. Such as &Vec<String>, all of these are FFI unfriendly and may cause unnecessary overhead under certain circumstances.
@georgbramm
Copy link
Collaborator

Still interested ?
we could do that with the next update

@georgbramm
Copy link
Collaborator

should be fixed now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants