為什么char與signed char或unsigned char不兼容？

Question

我發現C99標准有一個語句，它拒絕類型char和signed char / unsigned char類型之間的兼容性。

C99標准注35：

在limits.h中定義的CHAR_MIN將具有值0或SCHAR_MIN之一，這可用於區分這兩個選項。 無論做出何種選擇，char都是與其他兩種類型不同的類型，並且與兩者都不兼容。

我的問題是委員會為什么否認兼容性？ 理由是什么？ 如果char與signed char或unsigned char兼容，會發生什么可怕的事情嗎？

Answer 1

根源在編譯器歷史中。 八十年代基本上有兩種C方言：

1. 簽署普通字符的地方
2. 其中普通字符是未簽名的

哪些應該C89標准化？ C89選擇不標准化，因為它會使已經編寫的C代碼中的大量假設無效 - 標准人稱之為已安裝的基礎 。 所以C89做了K＆R做的事情：保留了普通字符實現定義的簽名。 如果您需要特定的簽名，請對您的字符進行限定。 現代編譯器通常允許您選擇帶有選項的方言（例如gcc的-funsigned-char ）。

如果忽略（un）signed char和plain char之間的區別，可能發生的“可怕”事情是，如果你在不考慮這些細節的情況下進行算術和移位，那么當你不期望它們時，你可能會得到符號擴展或者反之亦然（甚至在換檔時未定義的行為）。

還有一些愚蠢的建議，建議總是使用顯式簽名或無符號限定符聲明你的字符。 只要您只使用指向這些限定類型的指針，這就可以工作，但是只要處理字符串和字符串函數，它就需要丑陋的轉換，所有這些操作都是指向指向不兼容的指針，它是指定不兼容的演員。 這樣的代碼突然變成了大量丑陋的角色。

字符的基本規則是：

• 對字符串使用plain char ，如果需要將指針傳遞給使用plain char的函數
• 如果你需要做一點比特和轉換字節，請使用unsigned char
• 如果需要小簽名值，請使用signed char ，但如果空間不是問題，請考慮使用int

Answer 2

將signed char和unsigned char視為最小的算術，整數類型，就像有signed short / unsigned short ，以及int ， long int ， long long int等等。 這些類型都是明確的。

另一方面， char用於一個非常不同的目的：它是I / O的基本類型和與系統的通信。 它不是用於計算，而是用作數據單元。 這就是為什么你會發現char的命令行參數使用，在“串”的定義，在FILE*功能和其他的讀/寫類型IO功能，以及在例外嚴格別名規則。 故意不嚴格定義此char類型，以便允許每個實現使用最“自然”的表示。

這只是分離責任的問題。

（確實， char與布局兼容的是signed char和unsigned char ，所以你可以顯式地將一個轉換為另一個並返回。）