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 4c59f21..d98cdf6 100644
--- a/doc/go1.3.html
+++ b/doc/go1.3.html
@@ -136,17 +136,17 @@
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>
