Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • S syscall
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 7
    • Issues 7
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 9
    • Merge requests 9
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • redox-osredox-os
  • syscall
  • Merge requests
  • !33

WIP: Error doc

  • Review changes

  • Download
  • Email patches
  • Plain diff
Open Julien Férard requested to merge jferard/syscall:error_doc into master Nov 19, 2018
  • Overview 1
  • Commits 9
  • Pipelines 0
  • Changes 9

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?

Edited Nov 21, 2018 by Julien Férard
Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: error_doc