pull/1/head
chai2010 2015-12-24 14:56:23 +08:00
parent 427ac25df9
commit 343084fc47
1 changed files with 1 additions and 1 deletions

View File

@ -55,7 +55,7 @@ pT := uintptr(unsafe.Pointer(new(T))) // 提示: 錯誤!
雖然目前的Go語言實現還沒有使用移動GC譯註未來可能實現但這不該是編寫錯誤代碼僥幸的理由當前的Go語言實現已經有移動變量的場景。在5.2節我們提到goroutine的棧是根據需要動態增長的。當發送棧動態增長的時候原來棧中的所以變量可能需要被移動到新的更大的棧中所以我們併不能確保變量的地址在整個使用週期內是不變的。
在編寫本文時還沒有清晰的原則來指引Go程序員什麽樣的unsafe.Pointer和uintptr的轉換是不安全的參考 [Go issue7192](https://github.com/golang/go/issues/7192 . 譯註: 該問題已經關閉因此我們強烈建議按照最壞的方式處理。將所有包含變量地址的uintptr類型變量當作BUG處理同時減少不必要的unsafe.Pointer類型到uintptr類型的轉換。在第一個例子中有三個轉換——字段偏移量到uintptr的轉換和轉迴unsafe.Pointer類型的操作——所有的轉換全在一個表達式完成。
在編寫本文時還沒有清晰的原則來指引Go程序員什麽樣的unsafe.Pointer和uintptr的轉換是不安全的參考 [Issue7192](https://github.com/golang/go/issues/7192) . 譯註: 該問題已經關閉因此我們強烈建議按照最壞的方式處理。將所有包含變量地址的uintptr類型變量當作BUG處理同時減少不必要的unsafe.Pointer類型到uintptr類型的轉換。在第一個例子中有三個轉換——字段偏移量到uintptr的轉換和轉迴unsafe.Pointer類型的操作——所有的轉換全在一個表達式完成。
當調用一個庫函數併且返迴的是uintptr類型地址時譯註普通方法實現的函數不盡量不要返迴該類型。下面例子是reflect包的函數reflect包和unsafe包一樣都是采用特殊技術實現的編譯器可能給它們開了後門比如下面反射包中的相關函數返迴的結果應該立卽轉換爲unsafe.Pointer以確保指針指向的是相同的變量。