You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If the evaluation of x would cause a run-time panic, then the evaluation of &x does too.
What did you see instead?
Only Program 2 panics. Also, even though p is nil in Program 1, comparing it to nil evaluates to false. I assume this is due to the compiler seeing how p is initialized and optimizing the comparison out - if you pass it through interface{}, the comparison ends up returning true (presumably fooling this optimization).
Now, arguably it is fine to violate the spec in this case, as we're using unsafe to trick the compiler. I haven't tested if something similar happens if we'd, say, create a PROT_NONE mapping and do the same addressing (I assume it does, though). I just wanted to tell you about it after I found it.
The text was updated successfully, but these errors were encountered:
I used unsafe to create a []int with len/cap 1 and data pointing at 0:
That's not a legal slice. The compiler/runtime assume that a slice with a nonzero length has a non-nil data pointer.
Using unsafe you can always put the system into a weird state it wasn't prepared for. For example, a string with a negative length. Users of unsafe need to be prepared for all kinds of restrictions (that aren't specified anywhere).
I'm going to close this issue. I don't see anything actionable here. Unless you are proposing we remove optimizations to handle weird unsafe cases like this?
I haven't tested if something similar happens if we'd, say, create a PROT_NONE mapping and do the same addressing (I assume it does, though).
The spec makes no promises about non-zero faulting pointers. We currently crash (not panic) if we dereference one.
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I used unsafe to create a
[]int
with len/cap 1 and data pointing at 0:Program 1
Program 2
What did you expect to see?
According to the spec, both programs should panic:
What did you see instead?
Only Program 2 panics. Also, even though
p
isnil
in Program 1, comparing it tonil
evaluates tofalse
. I assume this is due to the compiler seeing howp
is initialized and optimizing the comparison out - if you pass it throughinterface{}
, the comparison ends up returning true (presumably fooling this optimization).Now, arguably it is fine to violate the spec in this case, as we're using
unsafe
to trick the compiler. I haven't tested if something similar happens if we'd, say, create aPROT_NONE
mapping and do the same addressing (I assume it does, though). I just wanted to tell you about it after I found it.The text was updated successfully, but these errors were encountered: