C 語言聯合體/指標轉換陷阱：為何浮點數以 %d 輸出為 0 的記憶體視角解析

經典 C 語言面試題：將 float 變數的位址轉為 int* 解引用，或透過 union { float f; int i; } 存取，發現 97.0f 對應的整數位元模式為 0x42C20000，但若直接 printf("%d", f) 輸出卻是 0。本文從 IEEE 754 浮點數表示、呼叫慣例、記憶體佈局三個層次徹底解釋。

現象重現

float f = 97.0f;
printf("%d\n", f);        // 輸出 0 (或亂碼，未定義行為)
printf("%f\n", f);        // 輸出 97.000000
printf("%d\n", *(int*)&f); // 輸出 1120403456 (0x42C20000)

核心原因：呼叫慣例與暫存器傳遞

x86-64 System V AMD64 ABI / Windows x64 呼叫慣例規定：

• 整數/指標參數：依序放入 RDI, RSI, RDX, RCX, R8, R9 (System V) / RCX, RDX, R8, R9 (Windows)。
• 浮點數參數：依序放入 XMM0~XMM7 (SSE 暫存器)。

printf("%d", f) 時，f 作為 **浮點數** 被放入 **XMM0**，但 %d 告訴 printf 「去整數暫存器 (RDI) 取值」。printf 讀取 RDI 內容（可能是殘留垃圾值或 0），導致輸出 0。

記憶體視角：IEEE 754 單精度浮點數佈局

97.0f 在記憶體中佔 4 字節，位元模式：

符號位(1) | 指數位(8) | 尾數位(23)
0         | 10000101  | 10000100000000000000000
= 0x42C20000

• 符號位 0 → 正數
• 指數位 133 - 127 (bias) = 6 → 2⁶ = 64
• 尾數 1.100001₂ = 1 + 0.5 + 0.03125 = 1.53125
• 值 = 1.53125 × 64 = 97.0

若以 int 讀取這 4 字節，得到 1120403456，**這是位元模式的整數解讀，而非數值轉換**。

為何 printf("%f", f) 正確？

%f 對應 double，float 會**預設提升為 double** 傳遞。ABI 規定浮點數參數無論 float 或 double 皆放入 XMM 暫存器（低 64 位）。printf 從 XMM0 讀取 64 位雙精度值，正確解讀為 97.0。

正確的跨型別輸出方式

避坑原則

1. 格式字串必須與實際參數型別匹配：%d 對應 int，%f 對應 double，%p 對應 void*。
2. 不要用指標轉換偷看浮點數位元：違反嚴格別名規則，可能觸發未定義行為（編譯器優化時假設不同型別指標不指向同一記憶體）。
   正規做法：union { float f; uint32_t u; } converter; converter.f = f; uint32_t bits = converter.u; (C99 保證有效)。
3. 開啟編譯器警告：-Wformat (GCC/Clang) 會檢測 printf 格式不匹配。

總結

浮點數以 %d 輸出為 0，是因為**呼叫慣例將浮點數放入向量暫存器，而 %d 讀取整數暫存器**造成的參數位置錯位。這不是浮點數「值為 0」，而是 printf 讀錯了地方。理解 ABI、IEEE 754、格式字串匹配，即可避開此類底層陷阱。

1. 上一篇文章： Android Byte[] 轉 Bitmap 圖片變花/重疊問題：旋轉矩陣導致的記憶體殘留與正確處理流程
2. 下一篇文章： Android Activity 間傳遞 Bitmap 陣列：靜態持有者模式優於 Intent 的最佳實務

程式設計綜合問答

C語言浮點數輸出全是0.0000：整數除法導致精度丟失

典型錯誤代碼 int a = 5, b = 2; float

jQuery LigerUI Grid toggleCol 顯示/隱藏欄位完整使用教學

功能簡介 toggleCol(columnId, visib

Java 環境變數 CLASSPATH、JAVA_HOME、JRE/lib/rt.jar 的角色差異

常見設定 JAVA_HOME=C:\Program File

C/C++ 實現五位整數數字降序重組完整教程

題目要求 輸入一個五位整數，將其五個數字按從大到小排序，組成