CONTRIBUTING.md

Contributing

Table of contents

1. What to do
2. Code style
3. Sending merge requests
4. Writing tests
5. Running tests

Maintaining a libc is tough work, and we'd love some help!

What to do

For now, we are still trying to get full libc compatibility before we move on to any optimisation.

• We currently have a number of unimplemented functions. Search for unimplemented!() and hop right in!
• If you notice any missing functionality, feel free to add it in

Code style

We have a rustfmt.toml in the root directory of relibc. Please run ./fmt.sh before sending in any merge requests as it will automatically format your code.

With regards to general style:

Where applicable, prefer using references to raw pointers

This is most obvious when looking at stdio functions. If raw pointers were used instead of references, then the resulting code would be significantly uglier. Instead try to check for pointer being valid with pointer::as_ref() and pointer::as_mut() and then immediately use those references instead.

Internal functions should always take references.

Use the c types exposed in our platform module instead of Rust's inbuilt integer types

This is so we can guarantee that everything works across platforms. While it is generally accepted these days that an int has 32 bits (which matches against an i32), some platforms have int as having 16 bits, and others have long as being 32 bits instead of 64. If you use the types in platform, then we can guarantee that your code will "just work" should we port relibc to a different architecture.

Use our internal functions

If you need to use a C string, don't reinvent the wheel. We have functions in the platform module that convert C strings to Rust slices.

We also have structures that wrap files, wrap writable strings, and wrap various other commonly used things that you should use instead of rolling your own.

Sending merge requests

If you have sent us a merge request, first of all, thanks for taking your time to help us!