Add getopt(3p) bindings for Rust #91
2 Participants
Notifications
Due Date
No due date set.
Blocks
#111 Testing for getopt and strerror bindings
bonsai/harakit
Reference: bonsai/harakit#91
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "getopt-bindings"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
@ -51,15 +51,14 @@ install: dist.PHONY: testtest: buildtests/posix-compat.sh$(RUSTC) --test src/getopt-rs/lib.rs -o build/test/getoptCould we make it so this file is testable the same way the last was?
I will see what I can do
See #111
Add getopt(3p) bindings for Rustto WIP: Add getopt(3p) bindings for RustWIP: Add getopt(3p) bindings for Rustto Add getopt(3p) bindings for Rust@trinity could you review this and rewrite the
swab.rsoption parsing stuff?This can be merged once @trinity rewrites the
swab(1)option parsing code to use the new API.Could we name the file in the heirarchy
libgetopt.rsto make it abundantly clear it's not a utility? Or (this may be not practically achievable) make this a utility that also functions as a library?The resulting rlib file will be called
liblibgetopt.rlibin this caseI was about to follow-up with the fact that
-owould fix this behavior but then I remembered we already do in fact use it already. I will rename the source file, should I rename strerror.rs to libstrerror.rs too?That would be very welcome.
I'm getting a build error on
libgetopt:Here are my versions on everything:
And here's my git status:
I committed my changes to swab(1) as I believe they will work, though I'm unable to test them at the moment.
This occurs because I was casting a Box to an
i8because on amd64 it is equivalent to ac_charbut on aarch64 ac_charis anu8. Making changes now.Word, let me go fix those real quick.
You can safely
.unwrap()this.I’m going to go ahead and fix the
swab(1)build so that I can merge this branch in.Pull request closed