dongpo1846 2018-02-07 01:24
浏览 27
已采纳

通过golang将对象编码为字节不安全?

func Encode(i interface{}) ([]byte, error) {
    buffer := bytes.NewBuffer(make([]byte, 0, 1024))
    // size := unsafe.Sizeof(i)
    size := reflect.TypeOf(i).Size()
    fmt.Println(size)
    ptr := unsafe.Pointer(&i)
    startAddr := uintptr(ptr)
    endAddr := startAddr + size
    for i := startAddr; i < endAddr; i++ {
        bytePtr := unsafe.Pointer(i)
        b := *(*byte)(bytePtr)
        buffer.WriteByte(b)
    }
    return buffer.Bytes(), nil
}

func TestEncode(t *testing.T) {
    test := Test{10, "hello world"}
    b, _ := Encode(test)
    ptr := unsafe.Pointer(&b)
    newTest := *(*Test)(ptr)
    fmt.Println(newTest.X)
}

I am learning how to use golang unsafe and wrote this function for encoding any object. I meet with two problems, first, dose unsafe.Sizeof(obj) always return obj's pointer size? Why it different from reflect.TypeOf(obj).Size()? Second, I want to iterate the underlying bytes of obj and convert it back to obj in TestEncode function by unsafe.Pointer(), but the object's values all corrupt, why?

  • 写回答

1条回答 默认 最新

  • dougu3290 2018-02-07 01:48
    关注

    First, unsafe.Sizeof returns the bytes that needs to store the type. It is a little bit tricky, but it does not mean bytes that needs to store the data.

    For example, a slice, as it is well known, stores 3 4-byte ints on a 32bit machine. One uintptr for memory address of the underlying array, and two int32 for len and cap. So no matter how long a slice is or what type it is of, a slice takes always 12 bytes on a 32 bit machine. Likely, a string uses 8 bytes: 1 uintptr for address and 1 int32 for len.

    As for difference between reflect.TypeOf().Size, it is about interface. reflect.TypeOf looks into the interface and gets an concrete type, and reports bytes needed about the concrete type, while unsafe.Sizeof just returns 8 for an interface type: 2 uintptr for a pointer to the data and a pointer to the method lists.

    Second part is quite clear now. For one, unsafe.Pointer is taking the address of the interface, instead of the concrete type. Two, in TestEncode, unsafe.Pointer is taking address to the 12-byte slice "header". There might be other errors, but with the two mentioned, they are meaningless to spot.

    Note: I avoid talking about orders of the uintptr and int32 not only because I don't know, but also becuase they are not documented, unsafe, and implentation depended.

    Note 2: Conclusion: Don't try to dump memory of a Go data.

    Note 3: I change everything to 32 bit becuase playground is using it, so it is easier to check.

    本回答被题主选为最佳回答 , 对您是否有帮助呢?
    评论

报告相同问题?