harmonize dirent->d_ino according to posix

[Mic92]

POSIX 2004 states that dirent shall include the field d_ino of type ino_t:
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html

Updated darwin/dragonfly/freebsd and netbsd definitions to met POSIX and make
portable use easier.

[Mic92]

motivation see nix-rust.

[semarie]

changing the name of dirent struct's member looks like a breaking change in libc. any Rust program relying on old name will not compile any more.

I am also a bit surprised that travis doesn't complain: a quick look at source code of BSDs show no d_ino field in dirent:

• FreeBSD
• NetBSD
• DragonFly (here it is present for KERNEL)

Maybe there is a #define somewhere ?

POSIX is only a specification, not all OSs follow it strictly.

[Mic92]

I would have made a define, however we have not equivalent in Rust. I suppose travis does not complain because binary compatibility is preserved. In the current form the definition it is unnecessary inconsistent also operating systems follow POSIX here from the semantics (Somebody just blindly copied the definition from the man pages). I can also work around this in nix in instead.

[Mic92]

It should be at least ino_t on all platforms.

[Mic92]

I fixed this in nix now. Once the pull request there is merged, I will also close this pull request:
nix-rust/nix@6ed79b0#diff-03012aeef26d4c7454d6dc08d0e31312R57

[alexcrichton]

Thanks for the PR! As this is a breaking change we can't merge this at this time, but I'll tag it as such.

[bors]

☔ The latest upstream changes (presumably #1217) made this pull request unmergeable. Please resolve the merge conflicts.

[gnzlbg]

@Mic92 could you rebase this ?

Also, do you have a link to the headers of each of the OSes this PR modifies? I'd like to check the name of this field in those headers. libc should do what those headers do. Like @semarie says, not all OSes follow POSIX properly, and this library should reflect that (nix doesn't have to do that though).

[Mic92]

@gnzlbg I can rebase once, it becomes clear that it will be merged (i.e. 1.0 is approaching). I strongly disagree that this crate should use the same names as the underlying libc's. They have it for historically reasons and C allows to make backwards-compatible aliases using macros, which cannot be done in Rust. This only makes platform-independent development unnecessary difficult for not good reason.

[gnzlbg]

This only makes platform-independent development unnecessary difficult for not good reason.

The only goal of this crate is to provide raw FFI bindings to the platform APIs "as is". This is particularly important for projects like bindgen, where they currently translate struct field names "as is" from the platform C code to Rust, and they expect that if the type exists in libc, its fields are named just like in the platform.

If we were to start translating platform API names here because we don't like their names, all C FFI binding generators would need to apply those exact translations to be able to use the libc crate.

I understand that working around platform incompatibilities is painful, and I understand that this has to be done in the nix crate to expose a portable API, but this is exactly what the nix crate is there for. If this was libc's goal, then arguably, the nix crate wouldn't have a reason to exist.