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.

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

报告相同问题?

悬赏问题

  • ¥15 Stata链式中介效应代码修改
  • ¥15 latex投稿显示click download
  • ¥15 请问读取环境变量文件失败是什么原因?
  • ¥15 在若依框架下实现人脸识别
  • ¥15 添加组件无法加载页面,某块加载卡住
  • ¥15 网络科学导论,网络控制
  • ¥15 利用Sentinel-2和Landsat8做一个水库的长时序NDVI的对比,为什么Snetinel-2计算的结果最小值特别小,而Lansat8就很平均
  • ¥15 metadata提取的PDF元数据,如何转换为一个Excel
  • ¥15 关于arduino编程toCharArray()函数的使用
  • ¥100 vc++混合CEF采用CLR方式编译报错