Export types from function signatures, or libc in general

[viraptor]

I've found that there's a number of types like pid_t which are either function results or arguments, but they're not explicitly exported. This means either I have to depend on libc myself and track the version nix depends on, or use a hacky solution (pid_t is available via nix::sys::ioctl::libc::pid_t).

It would be great if the types used in public signatures were either available through nix in a more straightforward way, or if the libc was available via nix::libc.

[kamalmarhubi]

Many of them are in sys/types.h (POSIX spec), so exporting at least those ones under nix::sys::types seems reasonable.

[carllerche]

This should be fixed... However, the exact strategy is still TBD (#190).

If an FFI type is used in a function signature, it should be exported by libc. However, nix may want to create its own types and wrap the libc FFI types in order to provide stricter type safety as well as custom functions on the types.

[viraptor]

The problem with types exported by libc is that cargo is a bit silly with pulling multiple libraries. (rust-lang/cargo#2064)

This results in "it's T, but not the right version of T" errors unless the local cargo.toml is kept in sync with nix's cargo.toml all the time. If nix forwarded just the plain pid_t (and other affected types), it would make the maintenance easier, because libc wouldn't have to be specified anymore.

[kamalmarhubi]

nix forwarded just the plain pid_t

What do you mean by this? I'm not all caught up on how the multiple versions of a Crate stuff works, but I definitely agree we want a good answer here.

[viraptor]

It's hard to explain in practice beyond "bad things happen if you don't ensure there's only one libc"... I'll try to create a minimal example.

[fiveop]

Suppose we have two versions of libc (A and B). Further assume that we have to libraries: foo and bar.
foo uses libc version A and bar, while bar uses libc version B.

Now if bar exports a function like this:

extern crate libc;
use libc;
fn baz(libc::c_int) {}

and foo uses it as follows

extern crate libc;
extern crate bar;
fn call_baz() {
   let a : libc::c_int = 3;
   baz(a);
}

then you'd get an error. Because a has type libc::c_int of version A, while baz expects an argument of type libc::c_int of version B.

If nix-rust exported libc under nix::libc. Then anyone using nix and libc could just depend on nix and use nix::libc for all its libc needs and thus ensure that he always has the right version for interoperability.

I don't suggest every library exports all its dependencies. But in this case nix and libc are so closely related, that I think it makes sense.

[kamalmarhubi]

Are there other alternatives to that? Seems a bit... icky!

[Susurrus]

I think this was resolved by #284. Though I do believe nix should only export its own datatypes that it uses so that downstream crates don't have this weird hybrid of importing from nix::libc or libc directly, which is currently the case.