1 回答
TA贡献1871条经验 获得超8个赞
这是因为您fullHashInputBytes通过附加到firstHalfinput1Bytesfirst 来创建:
fullHashInputBytes := append(firstHalfinput1Bytes, input2Bytes...)
这是一部分input1bytes:
firstHalfinput1Bytes := input1bytes[:8]
所以第一个追加可能会覆盖input1bytes索引高于 7 的 at 的内容,这实际上是 的内容secondHalfinput1Bytes:
secondHalfinput1Bytes := input1bytes[8:16]
因此,稍后当您还附加secondHalfinput1Bytes到时fullHashInputBytes,您可能最终会附加不同的内容。
这很可能不是您想要的。
如果你这样做“干净”:
var fullHashInputBytes []byte
fullHashInputBytes = append(fullHashInputBytes, firstHalfinput1Bytes...)
fullHashInputBytes = append(fullHashInputBytes, input2Bytes...)
// OPTIONAL print doesn't change anything:
fmt.Println("fullHashInputBytes", fullHashInputBytes)
// ...rest of your appends...
如果您在本地或在Go Playground上运行它,那么输出将是相同的。
为什么会出现异常行为?
您的第一个追加是否覆盖input1bytes取决于追加是否可以“就地”执行,而不必分配新的支持数组,这取决于 的容量firstHalfinput1Bytes,它是“继承”的input1bytes:
input1bytes := []byte(input1)
fmt.Println(cap(input1bytes))
(您可以在此处更详细地了解它:在 Go 中连接两个切片)。
转换 []byte(input)仅保证具有 的字节,input1但规范并未规定结果切片的容量应该有多大。它可能取决于平台/架构。在 Go Playground 上capacity = 16,在我的本地amd64架构上,我得到了上述转换结果capacity = 32。
最后一点:用于[]byte(input)转换结果切片的容量可能取决于您对结果切片的操作。如果您将其传递给,编译器可能会决定使用较低的容量,fmt.Println()因为这表明切片可能会逃逸。同样,编译器做出的决定不在您的掌控之中。
不要依赖这样的东西,不要编写依赖于转换结果切片容量的代码。以“干净”的方式进行:不要追加到新切片,firstHalfinput1Bytes而是追加到新切片。
- 1 回答
- 0 关注
- 137 浏览
添加回答
举报