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

Rust: no access to lm_inst_t properties. #217

Closed
MeguminSama opened this issue May 22, 2024 · 2 comments
Closed

Rust: no access to lm_inst_t properties. #217

MeguminSama opened this issue May 22, 2024 · 2 comments

Comments

@MeguminSama
Copy link
Contributor

MeguminSama commented May 22, 2024

I'm using LM_Assemble and LM_Disassemble to automatically update jmp instruction operands, but there's no way to access the internal properties of lm_inst_t.

At the moment, to get the assembly string, I'm having to to_string the result of LM_Disassemble, split by " ->", and grab the first item in the array.

Would it be reasonable to make the properties of lm_inst_t public, or to provide functions to get access to the mnemonic, op_str, etc?

using libmem = { git = "https://github.com/rdbo/libmem.git", rev = "70745c82453e9ea38d289ff02c4dfc324df5c1ec" }

@rdbo
Copy link
Owner

rdbo commented May 22, 2024

The fields in the structs are not public because the Rust wrapper needs to do convertions between C strings and Rust strings, for example. I probably just forgot to do it at the time.
The newer bindings will separate further the C API from the Rust API, where there will be a crate called libmem-sys (raw C bindings) and just libmem which will be more rusty
Those bindings are not complete yet, but when 5.0.0 releases, you should expect to be able to access them normally.
For the time being, best option might be to do functions like this in a fork:

impl lm_inst_t {
    pub fn get_mnemonic() -> String {
        string_from_cstring(&self.mnemonic)
    }
    
    pub fn get_op_str() -> String {
        string_from_cstring(&self.op_str)
    }
}

@MeguminSama
Copy link
Contributor Author

Thanks for the quick response!

I was just looking into it and noticed the big move to libmem-sys (and that the properties are public on there).

I've switched over to libmem-sys for the time being, rather than making a fork - since the changes on my end were fairly minimal :)

Thanks!

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