r? @JohnTitor

(rust-highfive has picked a reviewer for you, use r? to override)

Changing their types would break existing code, I'd prefer to follow https://github.com/rust-lang/libc/blob/master/CONTRIBUTING.md#breaking-change-policy first.

Thanks! @bors r

📌 Commit 00204b0 has been approved by JohnTitor

It is now in the queue for this repository.

⌛ Testing commit 00204b0 with merge a59c842...

☀️ Test successful - checks-actions, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13, checks-cirrus-freebsd-14
Approved by: JohnTitor
Pushing a59c842 to master...

This change is causing deprecation warnings downstream, and there's nothing that downstream crates can do about it except to suppress the warning. I don't think the policy laid out in https://github.com/rust-lang/libc/blob/master/CONTRIBUTING.md#breaking-change-policy is appropriate in this case. That policy would make sense if upstream really were changing an API, and especially if upstream were removing it. But in this case musl/emscripten didn't change anything. Instead, libc was simply wrong. I think libc should just go ahead and fix the definition for musl/emscripten.
A deprecation notice, IMHO, should only be used if there's some way for a downstream crate to be compatible with both the deprecated libc definitions and the fixed ones.

A deprecation notice, IMHO, should only be used if there's some way for a downstream crate to be compatible with both the deprecated libc definitions and the fixed ones.

Users can prepare the upcoming type changes if they depend on it.

This change is breaking CI for rustix (and probably other crates), which has deny(warnings) in the CI. And as @asomers already said, there is nothing (except allow(deprecated)) the user can do about this. Deprecating items is a mechanism for soft removal, not for announcing modifications to existing APIs.

Yes, as I mentioned here, these deprecations don't feel like the right way to handle API changes -- it makes sense to handle removals that way, but it's unclear what downstream users are supposed to do for changes other than #[allow(...)] them.

We should find an alternative approach though. I'm guessing an 0.3 is considered off the table?

I came here from the deprecation warnings spitted out, but I am deeply unclear given the above discussion what the expected alternative going forward is. These constants still seem to exist in glibc, so under what name can we expect them in the future?