Doesn't this risk causing a dangling reference since whatever quote or behavior the text was referring to might have gotten changed in the latest version?

View changes since the review

That is a risk. I manually checked all links with anchors, but not all plain links (without anchors). In this case the comment helpfully gives us a quote

"an error is returned if [...] the absolute time specified by abstime has already been passed at the time of the call"

Before https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_cond_timedwait.html:

The pthread_cond_timedwait() function shall be equivalent to pthread_cond_wait(), except that an error is returned if the absolute time specified by abstime passes (that is, system time equals or exceeds abstime) before the condition cond is signaled or broadcasted, or if the absolute time specified by abstime has already been passed at the time of the call. When such timeouts occur, pthread_cond_timedwait() shall nonetheless release and re-acquire the mutex referenced by mutex, and may consume a condition signal directed concurrently at the condition variable.

After https://pubs.opengroup.org/onlinepubs/9799919799/functions/pthread_cond_timedwait.html:

The pthread_cond_clockwait() function shall be equivalent to pthread_cond_wait(), except that an error is returned if the absolute time specified by abstime as measured against the clock indicated by clock_id passes (that is, the current time measured by that clock equals or exceeds abstime) before the condition cond is signaled or broadcasted, or if the absolute time specified by abstime has already been passed at the time of the call. Implementations shall support passing CLOCK_REALTIME and CLOCK_MONOTONIC to pthread_cond_clockwait() as the clock_id argument. When such timeouts occur, pthread_cond_clockwait() shall nonetheless release and re-acquire the mutex referenced by mutex, and may consume a condition signal directed concurrently at the condition variable.

The text changed a bit, but I read them to carry equivalent context. I think if there's a problem with updating the links, it would possibly need a code fix/change (as it would mean the spec changed, but the code didn't follow it).

So in other words, reviewing this PR requires carefully checking for each link you changed whether it still provides the right kind of context. That's quite a lot of work. I am not convinced it's worth the effort -- personally I don't have the spare review capacity to review PRs like this that are a lot of effort for little benefit. But I'm not the assigned reviewer, we can wait what @Darksonn says.

But for the Miri side, I am the main reviewer, and I don't think this PR provides enough benefit to justify the risk of semantically dangling references. So please remove the Miri changes.

Heard. Thanks for the review and for maintaining MIRI. I'll remove the MIRI commit.

I got the idea of doing this from my work on another doc PR #158574. There was an old link in the same source file, but I wasn't otherwise touching those docs. It felt wrong to standardize everything on the old edition. It also seemed somewhat unclear if updating that edition in the same PR was okay or not. I chose to leave it and update all of them at once in this PR.

I see a value in standardization. When there's divergence, programmers are primed to see intent in it. Part of me sending this PR is to answer "are these old on purpose or by accident." With the theory that others just hadn't noticed and updated them. Being intentionally old because they are point-in-time references is a reasonable maintenance trade-off.

I would still like to see them updated in Rust (if not in miri). I'm open to doing more legwork if it can help (like leaving more comments as I did here, walking through the check). I just didn't want to start off with that, as otherwise it could be a bit overwhelming. Also open to breaking up the review burden into more manageable chunks with multiple commits or PRs. I just didn't want y'all to feel like I was trying to game my commit numbers.