From: Russ Cox Date: Thu, 22 May 2014 15:45:03 +0000 (-0400) Subject: doc/go1.3.html: change uintptr to integer in unsafe.Pointer section X-Git-Tag: go1.3rc1~51 X-Git-Url: http://www.git.cypherpunks.su/?a=commitdiff_plain;h=8d8dab34eb3bedfbb0e384deaeb03a9395db89a8;p=gostls13.git 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 --- diff --git a/doc/go1.3.html b/doc/go1.3.html index 4c59f212cd..d98cdf629f 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.