Policy question: changes for platform consistency

[tgross35]

We have a couple PRs proposing something that makes platforms more consistent, but isn't exactly true to the C API. Two examples:

• stat has a field st_dev on almost all platforms, but on Hurd it is st_fsid. hurd: Fix st_dev name #3785 proposes renaming this field to st_dev.
• Event APIs in FreeBSD are part of the default C API in Linux, but in a separate package for BSD. FreeBSD: add evdev structures #3756 proposes adding these anyway.

The reasoning for these suggestions is that it is pretty unlikely for library authors to special case Hurd or BSD, meaning builds will just break on these platforms. By making something consistent with Linux, it is more likely that things work out of the box without library authors needing to test these less common platforms.

I think an argument could be made in either direction, so I am bringing this up as a more general policy question.

[tgross35]

@joshtriplett do you have any thoughts here?

[sthibaul]

but on Hurd it is st_fsid. #3785 proposes renaming this field to st_dev.

Note: the Hurd C API also provides the st_dev alias for the st_fsid field. So from the point of view of C, Hurd does provide the st_dev name for the field too.

[sthibaul]

And also, in the struct stat, it's already st_dev which is defined in rust-libc, it's struct stat64 which wasn't fixed yet in rust-libc to follow the common practice of calling it st_dev.

[sthibaul]

(put another way: if rust could support different names for the same field, we could ideally provide both st_dev and st_fsid. Otherwise, I'd say better provide the most standard variant, st_dev)

[sthibaul]

Are there any news on this?

[asomers]

Personally I'm against it. Attempting to provide compatibility shims in libc would obscure the crate's true purpose. We've tried the same thing in the Nix crate a few times, and it never turned out well. Compatibility layers are best built at a higher level than this.