[C 的那些眉角]NULL 不等於 0 — 指標的初始化問題

作者:

寫韌體寫久了，有些東西會變成肌肉記憶，手就是會自動打出來。指標宣告完順手 = NULL，這大概是每個 C 工程師的本能反應。

但前陣子在 debug 一個詭異的 crash，追了大半天才發現：問題出在我對 NULL、0、和「指標初始化」這幾件事的理解，其實一直有個模糊地帶。

事情是怎麼開始的

在一個專案裡，有一段大概長這樣的 code：

struct sensor_ctx {
    uint8_t *buf;
    uint16_t len;
    int (*callback)(uint8_t *data, uint16_t size);
};

void sensor_init(struct sensor_ctx *ctx)
{
    memset(ctx, 0, sizeof(*ctx));
    // 後面根據設定去 assign buf 和 callback
}

看起來超正常對吧？memset 把整個 struct 清成 0，指標欄位自然就是 NULL，之後再根據需要 assign。

這段 code 在我們的 ARM Cortex-M4 平台跑了好幾個月都沒事。直到有一天，同事把類似的邏輯搬到另一個比較冷門的平台上——然後 callback 呼叫就莫名 crash 了。

閱讀全文

[C 的那些眉角]指標與陣列的關係 — 從根本搞清楚

作者:

寫 C 寫了好幾年，我一直以為自己搞懂指標跟陣列的關係了。

直到有一次，我在一個跨檔案的專案裡，某個 .c 檔宣告了 char buf[256]，另一個 .c 檔用 extern char *buf 去引用它。編譯過了，連結也過了，一跑就 segfault。

我盯著螢幕看了十分鐘，心裡想：「這兩個不是一樣的東西嗎？」

不是。這篇就是要把這件事從根本講清楚。

🧠 陣列不是指標，指標不是陣列

先把結論放前面：陣列和指標是兩種完全不同的東西，只是在某些場景下行為很像，像到讓人誤以為它們是同一個東西。

int arr[5] = {10, 20, 30, 40, 50};
int *ptr = arr;

閱讀全文

[C 的那些眉角]迴圈陷阱—那些讓你 debug 到懷疑人生的邊界條件

作者:

寫 application 的迴圈出包，頂多程式 crash、重開就好。但在 firmware 的世界裡，一個迴圈的邊界條件沒處理好，輕則硬體不回應，重則系統直接掛死，debug 工具接上去什麼都看不到，只能對著 oscilloscope 發呆。

這篇整理的都是我這幾年踩過的坑，有些當下真的找很久，事後回頭看都覺得自己蠢。但這就是 firmware 的日常吧。

🔥 硬體暫存器輪詢：你以為它會回來，但它不會

這大概是 firmware 新手最容易中招的地方。輪詢一個硬體暫存器，等某個 bit 被設起來：

// ❌ 經典死法
while (!(REG_STATUS & STATUS_READY));

看起來很直覺對吧？但問題是——如果硬體永遠不 ready 呢？

閱讀全文

為什麼工程師要看股票？ 不是要當股神，是要對自己負責

作者:

記得剛出社會沒多久，有一件事讓我覺得很奇怪。

公司裡的工程師們，不管資歷深淺，午休時間幾乎人手一個看盤 App，偶爾三三兩兩討論一下某支股票。我那時候心想，大家不是來寫程式的嗎？幹嘛盯著那個。

後來有個前輩點醒了我：「你以後會需要懂一點股票，不是要靠它發財，是為了讓自己在職涯裡做出更好的決定。」

當時聽完覺得有點玄，現在回頭看，還真的是這樣。

看懂公司，才知道你在哪條船上

科技業的工作環境有個特性：公司的命運跟你的命運是綁在一起的。

閱讀全文

[C 的那些眉角]Bit 操作的乾淨寫法 — 告別 magic number

作者:

嵌入式開發幾乎離不開 bit 操作。

設定硬體暫存器、解析通訊協定封包、
控制 GPIO、讀取狀態旗標，
到處都是對特定 bit 的讀寫。

我剛開始寫嵌入式的時候，
程式碼長這樣：

// 設定 UART 控制暫存器
UART_CTRL |= 0x01; // 啟用 TX
UART_CTRL |= 0x02; // 啟用 RX
UART_CTRL &= ~0x04; // 關閉 loopback
UART_CTRL |= (0x03 << 4); // 設定 baud rate 為 115200

當下寫的時候覺得沒問題，
因為我知道每個數字代表什麼。

三個月後回來看，
完全不知道 0x01、0x02、0x04 是什麼意思，
要翻 datasheet 才能看懂。

這就是 magic number 的問題。

閱讀全文

[C 的那些眉角]volatile 到底是什麼 — 我花了很久才搞懂

作者:

volatile 是我學 C 語言以來，
花最久時間才真正搞懂的關鍵字。

不是因為語法複雜，
而是因為它的效果是「阻止編譯器做某些優化」，
在沒有優化的情況下，
加不加 volatile 看起來沒有差別，
讓人誤以為自己懂了。

直到有一天，開啟了 -O2 優化，
程式行為突然變了，
才發現原來自己一直用錯。

閱讀全文

[C 的那些眉角]switch 記得加 default — 防禦未來的自己

作者:

有一種 bug，不是今天的你造成的，
是三個月後的你造成的。

你現在寫了一個 switch，
處理三種狀態，邏輯完全正確，
測試也都過了。

三個月後，需求改了，
新增了第四種狀態。
你在 enum 裡加了一個值，
但忘記去更新那個 switch。

編譯過了，沒有警告，
程式跑起來，遇到第四種狀態的時候，
switch 什麼都不做，
靜靜地繼續往下執行。

症狀可能是某個功能沒有反應，
可能是某個變數沒有被更新，
可能要跑很久才會觸發那個狀態，
然後你花了半天才找到原因。

default 加一行，可以讓這種問題立刻現形。

閱讀全文

[C 的那些眉角]整數溢位比你想的更常見

作者:

有一個 bug，我在 code review 的時候無意間看到，
當下覺得「這不會有問題吧」，
但仔細算了一下，發現真的會出問題。

uint16_t a = 60000;
uint16_t b = 10000;
uint16_t sum = a + b; // 你覺得 sum 是多少？

答案不是 70000。

uint16_t 最大值是 65535，
70000 超過了，發生溢位，
sum 實際上是 70000 - 65536 = 4464。

程式繼續跑，用著這個錯誤的值，
後續的計算全部都錯了，
但不會 crash，不會有任何警告。

這就是整數溢位的恐怖之處。

閱讀全文

[C 的那些眉角]陣列邊界檢查 — 緩衝區溢位的根源

作者:

緩衝區溢位（Buffer Overflow）是 C 語言最惡名昭彰的問題之一。

它不只是會讓程式 crash，
在某些情況下，它是駭客攻擊的入口。
歷史上很多嚴重的安全漏洞，
根源都是一個沒有做邊界檢查的陣列存取。

但在嵌入式開發，我更常遇到的不是安全問題，
而是「程式跑著跑著，某個全域變數的值莫名其妙被改掉」，
或是「UART 收到一個比預期長的封包，程式就 crash 了」。

追到最後，都是同一件事：
有人寫到了陣列邊界以外的地方。

閱讀全文