為什麼 Unix/Linux 系統 API 偏愛 int？類型設計背後的文化基因

提問：為何不統一用 size_t/unsigned int？

讀者「和平」觀察到：C++ Primer 建議容量類變量用 size_t（無符號、語義清晰），但 Linux 系統調用大量使用有符號 int。這看似浪費一半表示範圍，實則蘊含深刻的工程文化差異。

兩種 API 設計哲學的對決

Unix 用 int 的三大工程紅利

1. 統一資源句柄模型：文件描述符、Socket、進程 ID、線程 ID、用戶 ID、設備號全是 int。內核以數組/哈希表索引，O(1) 查找，極致高效。
2. 負數語義天然承載錯誤狀態：read(fd, buf, n) 成功返回 ≥0 字節數，失敗返回 -1。無需額外 bool& success 參數，也無需犧牲最大值作為哨兵（如 Windows INVALID_HANDLE_VALUE）。
3. 接口極簡，組合靈活：同一組 read/write/close/ioctl 操作文件、管道、Socket、終端、設備。int 的通用性支撐了「一切皆文件」的系統抽象。

反面教材：Windows SOCKET 的無符號陷阱

typedef unsigned int SOCKET;  // 實為 UINT_PTR
#define INVALID_SOCKET (SOCKET)(~0)  // 0xFFFFFFFF

導致 accept() 等函數無法用返回值直接判斷成敗，必須額外檢查 == INVALID_SOCKET。更糟的是，SOCKET 實際範圍遠小於 32 位，高位永遠浪費。Unix 直接用 int sockfd，-1 即錯誤，簡潔有力。

「夠用」原則：int 範圍真的不夠嗎？

• Socket 端口上限 65535，int 21 億倍富餘
• 單次 read/write 受限於內存/協議窗口，極少超 2GB
• 真正需要 64 位時（大文件偏移），另有 off_t/size_t 專用類型

夠用就好，避免過度設計——這是 Unix 實用主義的核心。

我的混合風格實踐

《0bug-C/C++商用工程之道》工程庫採用：

• Windows 風格命名法（匈牙利變量前綴、清晰類型別名）
• Unix 風格 API 契約（int 返回值、-1 表錯、0/正數表成功）
• 關鍵容量參數用 size_t/uint32_t 明確語義

白貓黑貓，抓到耗子就是好貓。工程無教條，合用為王。