search

rust-lang / libc

Raw bindings to platform APIs for Rust
https://docs.rs/libc
Apache License 2.0
2.06k stars 1.03k forks source link

Policy question: changes for platform consistency #3839

Open tgross35 opened 4 weeks ago

tgross35 commented 4 weeks ago

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

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 commented 4 weeks ago

@joshtriplett do you have any thoughts here?

sthibaul commented 4 weeks ago

but on Hurd it is st_fsid. https://github.com/rust-lang/libc/pull/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 commented 4 weeks ago

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 commented 4 weeks ago

(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)