Closed carlvoller closed 3 months ago
Thank you so much for your work! Since #34 included only minor refactoring, it might be possible that it was created by an AI tool - so good catch in that case.
LGTM!
is this a part of the newest release yet
It's not released yet! I'll make sure to create a release in the coming week 👍
Hi there!
First of, I love the work you've done with Lurk. Thank you so much for creating this!
I noticed that Lurk didn't support arm64, so thought I'd help you out with adding the syscall tables for you. (It was almost the same as the RiscV64 stuff that was added previously, so most credit to the guy that added that)
However, I encountered some issue after adding the arm64 syscall tables, mainly that the syscalls that accepted a String argument wasn't processed properly. I thought this was an issue with my implementation, until I tried to
cargo install lurk-cli
on an x86 machine and realised it had the same issue. String outputs were being appended lots of NULL bytes and other random characters.I found the culprit to be Pull Request #34. It appears that the contributor asserts that some syscalls that accepts a
const char *
will not always accept a String? I'm not actually too sure what they were trying to assert as the example ofwrite()
that they gave ofthe write syscall may write bytes to devices instead of a C string.
doesn't appear to relate at all to parsing the arguments of a syscall?Furthermore, the text in their PR seems to fail multiple online (free) AI detectors. So I am inclined to mistrust its legitimacy a little. (So sorry in advance if I am wrong though!)
After reversing PR #34 and fixing both
src/arch/riscv64.rs
andsrc/arch/x86_64.rs
to use String instead, I compared the output of Lurk to strace and the outputs match again.Would love to hear any thoughts on the above. Once again, thank you so much for creating Lurk!