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 4c59f212cd419eec92889b13a5c12bddeaf566db..d98cdf629fdaaff3eecd52030784433cb2580f1d 100644 (file)
--- 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 <a href="/pkg/unsafe/">package unsafe</a>
-to store <code>uintptrs</code> 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 <a href="/pkg/unsafe/">package unsafe</a> to store pointers
-in <code>uintptr</code> 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
 <a href="http://en.wikipedia.org/wiki/Dangling_pointer">dangling pointers</a>.
 </p>
 
 <p>
-<em>Updating</em>: Code that converts a <code>uintptr</code> value stored in memory
-to <code>unsafe.Pointer</code> is illegal and must be rewritten.
+<em>Updating</em>: Code that uses <code>unsafe.Pointer</code> to convert
+an integer-typed value held in memory into a pointer is illegal and must be rewritten.
 Such code can be identified by <code>go vet</code>.
 </p>