Decide on conventions for using #[inline]

[kamalmarhubi]

Raised by @fiveop in a comment on #332.

I think we can safely agree that any time we simply do

fn some_fn() {
    let res = unsafe { libc::some_fn() };
    Errno::result(res)

that the function can be safely marked #[inline]. In #332, I marked our fork() wrapper as #[inline] which does slightly more work.

Given the purpose of nix, I feel that we should be able to mark almost every function in it as #[inline]. They are small adapters and wrappers, so the code size at call sites shouldn't grow much if the compiler chooses to inline them.

I'd be interested in examples where #[inline] would seem like a bad idea. The only one that jumps to mind immediately is execvpe(), which already is behind a feature and is a bit different from most of nix.

NB the #[inline] attribute is a hint to the compiler that it should inline. There are also #[inline(always)] and #[inline(never)] variants that do what you'd expect. The reference has more: http://doc.rust-lang.org/reference.html#inline-attributes

[fiveop]

As a rule, I would suggest that "we mark every function #[inline], that only calls a libc function and wraps the result in a rust idomatic fashion." This will cover probably every function we have, but I don't mind.

[kamalmarhubi]

Does the "idiomatic Rust fashion" part cover what we do in fork()?

[fiveop]

That part refers to the result (or Result :)) and not the code creating the result. That's a different problem. Of course, we always want to write idiomatic rust, but whether we achieve it is another matter.

[kamalmarhubi]

:-)

[posborne]

Sounds reasonable to me as a general (but not absolute rule). As things evolve, I'm sure we'll run across some exceptions.