syscall merge requests
https://gitlab.redox-os.org/redox-os/syscall/-/merge_requests
2019-01-06T20:16:08Z
https://gitlab.redox-os.org/redox-os/syscall/-/merge_requests/33
WIP: Error doc
2019-01-06T20:16:08Z
Julien FĂ©rard
WIP: Error doc
I'm working on `syscall/src/error.rs`. *I don't expect this to be merged, because it would break a lot of code*. It's more a list of proposals than a merge request or an invitation to discuss.
First of all, I added some comments and t...
I'm working on `syscall/src/error.rs`. *I don't expect this to be merged, because it would break a lot of code*. It's more a list of proposals than a merge request or an invitation to discuss.
First of all, I added some comments and tests. Just run `cargo test` to see the test results.
In the first commit, I also added some boundary checks on `Error::new` and `Error::mux`. The main idea is that one should not be allowed to create an error without using a predefined constant, or trying to mux a huge `Ok` value. This must trigger a panic and be fixed in the kernel.
I also removed the public access to `STR_ERROR`. I think that a module should expose services rather than data. The only use of `STR_ARRAY` I could find is: "given an `errno`, what is the error description?". Why not give directly this service?
Second commit: I was rather confused by an `Error::demux` returning `Ok`. I expected it to always return an `Error`. I created a `result` module for `Result`, `mux` and `demux`. When I read `result::demux`, it seems clear to me that I will get a `Result`. That may seem a detail, but if the code is easy to read, you avoid bugs.
Obviously, this would break a lot of libraries!
What do you think about this?
https://gitlab.redox-os.org/redox-os/syscall/-/merge_requests/12
[WIP] [POC] Proc macro for handling system call ABI
2018-06-24T21:48:03Z
Ian Douglas Scott
[WIP] [POC] Proc macro for handling system call ABI
This definitely shouldn't be merged currently, and perhaps should never be used, but I thought I might as well put it in a PR for reference.
This definitely shouldn't be merged currently, and perhaps should never be used, but I thought I might as well put it in a PR for reference.