In Go, is there any way to access private fields o

Question

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)?

Answer 1

I am just starting out with C++ -> Go porting and I ran across a pair of classes that were friends with each other. I am pretty sure if they are part of the same package they are friends by default, effectively.

The upper case first letter for an identifier is bound within the package. Thus they can be in separate files so long as they are in the same directory, and will have the ability to see each other's unexported fields.

Using reflect, even if it is Go stdlib, is something you should think always carefully about. It adds a lot of runtime overhead. The solution would be basically copy&paste if the two struct types you want to be friends, they simply must be in the same folder. Otherwise you have to export them. (Personally I think the woo woo about the 'risk' of exporting sensitive data is quite overblown, although if you are writing a solitary library that has no executable, maybe there can be some sense to this since users of the library will not see these fields in the GoDoc and thus not think they can depend on their existence).

Answer 2

There is a way to read unexported members using reflect

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

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.

Edit: Here's a slightly safer way to do it:

func change_foo(f *Foo) {
    // Note, simply doing reflect.ValueOf(*f) won't work, need to do this
    pointerVal := reflect.ValueOf(f)
    val := reflect.Indirect(pointerVal)

    member := val.FieldByName("y")
    ptrToY := unsafe.Pointer(member.UnsafeAddr())
    realPtrToY := (**Foo)(ptrToY)
    *realPtrToY = nil // or &Foo{} or whatever

}

This is safer, as it will always find the correct named field, but it's still unfriendly, probably slow, and I'm not sure if it messes with garbage collection. It will also fail to warn you if you're doing something weird (you could make this code a little safer by adding a few checks, but I won't bother, this gets the gist across well enough).

Also keep in mind that FieldByName is susceptible to the package developer changing the name of the variable. As a package developer, I can tell you that I have absolutely no qualms about changing the names of things users should be unaware of. You could use Field, but then you're susceptible to the developer changing the order of the fields with no warning, which is something I also have no qualms about doing. Keep in mind that this combination of reflect and unsafe is... unsafe, unlike normal name changes this won't give you a compile time error. Instead, the program will just suddenly panic or do something weird and undefined because it got the wrong field, meaning even if YOU are the package developer that did the name change, you still may not remember everywhere you did this trick and spend a while tracking down why your tests suddenly broke because the compiler doesn't complain. Did I mention that this is a bad idea?

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.