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 乘性高斯噪声在深度学习网络中的应用
  • ¥15 运筹学排序问题中的在线排序
  • ¥15 关于docker部署flink集成hadoop的yarn,请教个问题 flink启动yarn-session.sh连不上hadoop,这个整了好几天一直不行,求帮忙看一下怎么解决
  • ¥30 求一段fortran代码用IVF编译运行的结果
  • ¥15 深度学习根据CNN网络模型,搭建BP模型并训练MNIST数据集
  • ¥15 C++ 头文件/宏冲突问题解决
  • ¥15 用comsol模拟大气湍流通过底部加热(温度不同)的腔体
  • ¥50 安卓adb backup备份子用户应用数据失败
  • ¥20 有人能用聚类分析帮我分析一下文本内容嘛
  • ¥30 python代码,帮调试,帮帮忙吧