Is there any way to access private fields of a struct from another package?
I have a struct in one package that has private fields:
package foo
type Foo struct {
x int
y *Foo
}
And another package (for example, a white-box testing package) needs access to them:
package bar
import "../foo"
func change_foo(f *Foo) {
f.y = nil
}
Is there a way to declare bar
to be a sort of "friend" package or any other way to be able to access foo.Foo
's private members from bar
, but still keep them private for all other packages (perhaps something in unsafe
)?
Solution 1:
There is a way to read unexported members using reflect (in Go < 1.7)
func read_foo(f *Foo) {
v := reflect.ValueOf(*f)
y := v.FieldByName("y")
fmt.Println(y.Interface())
}
However, trying to use y.Set, or otherwise set the field with reflect will result in the code panicking that you're trying to set an unexported field outside the package.
In short: unexported fields should be unexported for a reason, if you need to alter them either put the thing that needs to alter it in the same package, or expose/export some safe way to alter it.
That said, in the interest of fully answering the question, you can do this (and have to do it this way in Go >= 1.7)
func change_foo(f *Foo) {
// Since structs are organized in memory order, we can advance the pointer
// by field size until we're at the desired member. For y, we advance by 8
// since it's the size of an int on a 64-bit machine and the int "x" is first
// in the representation of Foo.
//
// If you wanted to alter x, you wouldn't advance the pointer at all, and simply
// would need to convert ptrTof to the type (*int)
ptrTof := unsafe.Pointer(f)
ptrTof = unsafe.Pointer(uintptr(ptrTof) + uintptr(8)) // Or 4, if this is 32-bit
ptrToy := (**Foo)(ptrTof)
*ptrToy = nil // or *ptrToy = &Foo{} or whatever you want
}
This is a really, really bad idea. It's not portable, if int ever changes in size it will fail, if you ever rearrange the order of the fields in Foo, change their types, or their sizes, or add new fields before the pre-existing ones this function will merrily change the new representation to random gibberish data without telling you. I also think it might break garbage collection for this block.
Please, if you need to alter a field from outside the package either write the functionality to change it from within the package or export it.
Edit2: Since you mention White Box testing, note that if you name a file in your directory <whatever>_test.go
it won't compile unless you use go test
, so if you want to do white box testing, at the top declare package <yourpackage>
which will give you access to unexported fields, and if you want to do black box testing then you use package <yourpackage>_test
.
If you need to white box test two packages at the same time, however, I think you may be stuck and may need to rethink your design.
Solution 2:
I assume what you're testing is a package functionality that changes the state of that package's object, but you want to verify the internals post that change to affirm the new state is correct.
What might help would be writing Get
and Set
function for the private fields, so they can be accessed beyond the package scope.
package foo
type Foo struct {
x int
y *Foo
}
func (f *Foo) GetY() *Foo {
return f.y
}
func (f *Foo) SetY(newY *Foo) {
f.y = newY
}
Note that the idea of these Get
and Set
is to limit read and/or write access to the fields, while directly exporting them gives them read+write access automatically always. A subtle difference but worth consideration if the true goal is to only read the private fields and not operate on them (which the package internals would do in there own way)
Finally, if you're not comfortable with adding these type of wrappers for all the private fields in your package, then you can write them in a new file within that package and use build tags to ignore it in your regular builds, and include it in your test builds (wherever/however you trigger your testing).
// +build whitebox
// Get() and Set() function
go test --tags=whitebox
Regular builds ignore building test files along with them, so these wont come in your final binary. If this package is used elsewhere in entirely different ecosystem, then this file wouldn't be built still because of the build tags constraint.