爲什麼參數類型的`putwchar（）`，`fputwc（）`和`putwc（）`不是`wint_t`？

Question

引入了wchar_t的ISO C90標準並沒有說明關於該表示的任何具體內容。它只需要 這種類型能夠存儲基本字符集的所有元素。

這意味着wchar_t可能是char類型，並且wint_t可以是int類型的 。此外，在一些實現中，wchar_t可以被簽名， 並且在一些 - 無符號的。情況與putchar()有何不同？

爲了比較，的putchar()，putc()和fputc() 參數選擇爲int。

我認爲，沒有任何的庫函數，其處理單 字符char（僅適用於int）工作，因爲即使 他們中的一些不使用EOF（像putchar()），我們不能使其char類型， 因爲如果它是char，我們強制轉換爲unsigned char（的char的符號性不規範），就不會有像

void f(char c) { ... 
... 
int x = 't'; 
f((unsigned char)x); 
... 

warning: conversion to ‘char’ from ‘unsigned char’ may change the sign of the result 

S型 轉換警告o唯一的選擇是使它成爲int，它可以保存簽名和未簽名的char。

儘管通過putchar（）函數自變量轉換爲unsigned char，即使它是作爲int或signed char傳遞的，但在putwchar（）函數中不會執行任何操作。

那麼，爲什麼fputwc()，putwc()和putwchar()採取wchar_t，不wint_t？看起來像標準中的缺陷。我錯過了明顯的東西嗎？

參見​​和Why argument type of putchar(), fputc() and putc() is not char?和Inconsistency in definitions of fputwc(), putwc() and putwchar() in glibc

---

UPDATE

如果wchar_t被定義爲char從glibc的參考一些報價wint_t必須定義爲類型由於參數提升。

這將是合法的定義wchar_t爲char

是事實，這些功能已經在 「ISO工作文件SC22/WG14/N204月31日1992年3月」 正確的接口（其中是發佈「ISO/IEC 9899：1990 /修訂版1：1995」之前的最終草案），但在「ISO/IEC 9899：1990 /修訂版1：1995」中進行了修改。看到這裏http://www.unix.org/version2/whatsnew/login_mse.html

Answer 1

這是一個有趣的問題，但不幸的是我認爲答案是由於歷史原因。這個答案的其餘部分只是我的看法，我沒有提及它。

的fputc家庭由於K & R C，第一版本，其中的功能原型根本不存在存在：你應該知道什麼參數類型接受一個函數，沒有可能發生在函數調用隱式轉換。由於fgetc家人返回一個int，它決定對稱fputc人會採取一個int參數，讓下面的結構：

fputc(fgetc(fd1), fd2); 

如果fputc採取了字符，它應該被寫（K & RC）：fputc((char) fgetc(fd1), fd2);。

但是現在，只有恐龍才能記得K & R，並且在函數調用中會發生隱式轉換。因此，當寬字符集功能被添加到標準庫時，決定只通過用於避免雙重轉換的部分，因爲僅使用wchar_t，因此避免了雙重轉換wchar_t - >wint_t - >wchar_t。而且它是在fputs定義明確的（強調礦）：

int fputc(int c, FILE *stream);
描述：的fputc功能通過流寫入由C（轉換爲unsigned 炭）到輸出流中指定的字符指向...

所以它不是很連貫，但我想，沒有人真正認爲有必要改變舊fputc家庭功能的定義...