aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/link
diff options
context:
space:
mode:
authorMichael Anthony Knyszek <mknyszek@google.com>2025-01-23 15:51:35 +0000
committerGopher Robot <gobot@golang.org>2025-03-28 13:50:18 -0700
commit5ec76ae5aa965208d820a0bde8f0abd685c17ecc (patch)
treece4880d267168d862cced09bc535095a23e1e824 /src/cmd/link
parent8f6c083d7bf68a766073c50ceb8ea405a3fe7bed (diff)
downloadgo-5ec76ae5aa965208d820a0bde8f0abd685c17ecc.tar.xz
weak: clarify Pointer equality semantics
The docs currently are imprecise about comparisons. This could lead users to believe that objects of the same type, allocated at the same address, could produce weak pointers that are equal to previously-created weak pointers. This is not the case. Weak pointers map to objects, not addresses. Update the documentation to state precisely that if two pointers do not compare equal, then two weak pointers created from those two pointers are guaranteed not to compare equal. Since a future pointer pointing to the same address is not comparable with a pointer produced *before* an object at that address has been reclaimed, this is sufficient to explain that weak pointers map 1:1 with object offsets, not addresses. (An object slot cannot be reused unless that slot is unreachable, so by construction, there's never an opportunity to compare an "old" and "new" pointer unless one uses unsafe tricks that violate the unsafe.Pointer rules.) Fixes #71381. Change-Id: I5509fd433cde013926d725694d480c697a8bc911 Reviewed-on: https://go-review.googlesource.com/c/go/+/643935 Reviewed-by: Carlos Amedee <carlos@golang.org> Auto-Submit: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Filippo Valsorda <filippo@golang.org>
Diffstat (limited to 'src/cmd/link')
0 files changed, 0 insertions, 0 deletions