code review 8494045: reflect: document the unreliability of StringHeader and...

reflect: document the unreliability of StringHeader and SliceHeader

[r, 2013-04-08 01:37:20]

Hello golang-dev@googlegroups.com,

I'd like you to review this change to
https://code.google.com/p/go/

[adg, 2013-04-08 01:39:08]

LGTM

[dvyukov, 2013-04-08 01:41:35]

LGTM

[r, 2013-04-08 01:42:00]

Anyone else?

-rob

[r, 2013-04-08 01:42:36]

*** Submitted as https://code.google.com/p/go/source/detail?r=1f43d831c825 ***

reflect: document the unreliability of StringHeader and SliceHeader

R=golang-dev, adg, dvyukov
CC=golang-dev
https://codereview.appspot.com/8494045

[bradfitz, 2013-04-08 02:56:58]

https://codereview.appspot.com/8494045/diff/4002/src/pkg/reflect/value.go
File src/pkg/reflect/value.go (right):

https://codereview.appspot.com/8494045/diff/4002/src/pkg/reflect/value.go#new...
src/pkg/reflect/value.go:1706: // a separate, correctly typed pointer to the
underlying data.
s/correctly typed/correctly-typed/ ?

"so programs must keep a separate string or correctly-typed pointer to..."

Also, I know we don't use the word "reference", but "pointer" feels weird here,
considering we're talking about a string, where the pointer isn't typically
visible.  On one hand, I'm sure anybody using reflect+unsafe knows what they're
doing (eventually), but it also invites questions about why this is uintptr
instead of *byte or, and whether *string is needed to keep it alive.

Calling out "string" somehow like above might clarify both.  Or noting that that
uintptr is for historical compatibility reasons.

Maybe this is bike shedding, though.

[r, 2013-04-08 04:06:41]

https://codereview.appspot.com/8494045/diff/4002/src/pkg/reflect/value.go
File src/pkg/reflect/value.go (right):

https://codereview.appspot.com/8494045/diff/4002/src/pkg/reflect/value.go#new...
src/pkg/reflect/value.go:1706: // a separate, correctly typed pointer to the
underlying data.
On 2013/04/08 02:56:58, bradfitz wrote:
> s/correctly typed/correctly-typed/ ?

it's correct as is. we're not making an adjective.

> "so programs must keep a separate string or correctly-typed pointer to..."

it's a pointer to the data. if you (not you, but some other you) need that
explained to you, and you don't understand that a string includes a pointer, you
shouldn't be within a hundred yards of this type.