go/test/fixedbugs/issue40954.go
Keith Randall 42b023d7b9 cmd/cgo: use go:notinheap for anonymous structs
They can't reasonably be allocated on the heap. Not a huge deal, but
it has an interesting and useful side effect.

After CL 249917, the compiler and runtime treat pointers to
go:notinheap types as uintptrs instead of real pointers (no write
barrier, not processed during stack scanning, ...). That feature is
exactly what we want for cgo to fix #40954. All the cases we have of
pointers declared in C, but which might actually be filled with
non-pointer data, are of this form (JNI's jobject heirarch, Darwin's
CFType heirarchy, ...).

Fixes #40954

Change-Id: I44a3b9bc2513d4287107e39d0cbbd0efd46a3aae
Reviewed-on: https://go-review.googlesource.com/c/go/+/250940
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
2020-09-16 17:26:46 +00:00

36 lines
840 B
Go

// run
// Copyright 2020 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
package main
import (
"unsafe"
)
//go:notinheap
type S struct{ x int }
func main() {
var i int
p := (*S)(unsafe.Pointer(uintptr(unsafe.Pointer(&i))))
v := uintptr(unsafe.Pointer(p))
// p is a pointer to a go:notinheap type. Like some C libraries,
// we stored an integer in that pointer. That integer just happens
// to be the address of i.
// v is also the address of i.
// p has a base type which is marked go:notinheap, so it
// should not be adjusted when the stack is copied.
recurse(100, p, v)
}
func recurse(n int, p *S, v uintptr) {
if n > 0 {
recurse(n-1, p, v)
}
if uintptr(unsafe.Pointer(p)) != v {
panic("adjusted notinheap pointer")
}
}