From 8d8dab34eb3bedfbb0e384deaeb03a9395db89a8 Mon Sep 17 00:00:00 2001 From: Russ Cox Date: Thu, 22 May 2014 11:45:03 -0400 Subject: [PATCH] doc/go1.3.html: change uintptr to integer in unsafe.Pointer section The key property here is what the bit pattern represents, not what its type is. Storing 5 into a pointer is the problem. Storing a uintptr that holds pointer bits back into a pointer is not as much of a problem, and not what we are claiming the runtime will detect. Longer discussion at https://groups.google.com/d/msg/golang-nuts/dIGISmr9hw0/0jO4ce85Eh0J LGTM=r R=r CC=golang-codereviews https://golang.org/cl/98370045 --- doc/go1.3.html | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/go1.3.html b/doc/go1.3.html index 4c59f212cd4..d98cdf629fd 100644 --- a/doc/go1.3.html +++ b/doc/go1.3.html @@ -136,17 +136,17 @@ contain pointers and other values do not. This assumption is fundamental to the precise behavior of both stack expansion and garbage collection. Programs that use package unsafe -to store uintptrs in pointer values are illegal and will crash if the runtime detects the behavior. +to store integers in pointer-typed values are illegal and will crash if the runtime detects the behavior. Programs that use package unsafe to store pointers -in uintptr values are also illegal but more difficult to diagnose during execution. +in integer-typed values are also illegal but more difficult to diagnose during execution. Because the pointers are hidden from the runtime, a stack expansion or garbage collection may reclaim the memory they point at, creating dangling pointers.

-Updating: Code that converts a uintptr value stored in memory -to unsafe.Pointer is illegal and must be rewritten. +Updating: Code that uses unsafe.Pointer to convert +an integer-typed value held in memory into a pointer is illegal and must be rewritten. Such code can be identified by go vet.