strchr() の第2引数はなぜ int 型なのでしょうか

Question

もしかすると、ちょい前の質問(https://okauth.okwave.jp/qa4151232.html)と同じことを聞いているような気もしますが、気にせずポスト。

その質問を読んだ時に strchr() のマニュアルを見たわけなんですが、そのプロトタイプ宣言は

char* strchr(const char* s, int c);

なんですね。どうして第 2 引数の型が int なのでしょう？「文字」c を検索するんだから普通に考えれば char ではないかと思うのですが、誰か教えて下さい。

ソースはこんな感じだったので、int である必要はないように思えるのですがどうなんでしょうか？
負数を与えたときに「何らかの動作」を期待してのことなのでしょうか？

char* strchr(const char* s, int c)
{
　char ch;
　ch = c;               /* <= 結局 char 型にしている */
　for ( ; ; ++s) {
　　if ( *s == ch ) {
　　　return (char*)s;
　　}
　　if ( *s == '\0' ) {
　　　return NULL;
　　}
　}
}

jacta · Accepted Answer

C++やC99では関数を呼び出す際には関数原型が必須ですが、以前の規格では可変個引数を持つもの（printfなど）を除けば、標準関数は関数原型なしで呼び出してもよいことになっていました。

関数原型なしで関数を呼び出した場合、既定の実引数拡張によって、char型はintまたはunsigned int型に暗黙的に型変換されます。これがstrchrやisalphaなどの引数がcharではなくintであることの直接の理由だと思います。

_himajin_ · Answer

またしても無駄な蛇足が増えて必要な補足が足りず、、、すみません。

> 「文字」をメモリの中から区別して表現するためには char では足らない状況があったため、
『「文字」を（文字以外の何かを含むかも知れない）メモリの中から区別して表現するためには char では足らない』状況があったんじゃ無かろうか、それにあわせてintになっているのではないか、と言う推測でした。

ちなみにワードマシンのくだりは以下のページなどを参考にしてますが、実際に確認したわけではないので#9とどちらが正しいのかはわかりません。
http://www.amy.hi-ho.ne.jp/~lepton/program/p5/prog512.html

> スタックポインタ(IA-32ではESPレジスタやEBPレジスタ)はレジスタは指しません
これについては解釈を間違えてたようです。すみません、指摘ありがとうございます。> #10

関数に渡す際に拡張される件についてはJIS X3010:2003 の 6.5.2.2 関数呼び出し から一部抜粋
呼び出される関数を表す式が、関数原型を含まない型を持つ場合、各実引数に対して整数拡張を行い、型floatを持つ実引数は型doubleに拡張する。
（中略）
呼び出される関数を表す式が関数原型を含む型を持つ場合、実引数は代入と同じ規則で、対応する仮引数の型に暗黙に変換する。

と書いてて気づきました。#11の「C90では、可変個引数を持つものを除き、標準ライブラリ関数を関数原型（プロトタイプ）なしで呼び出してもよいことになっています。」が仕様として定められていたなら（かつ、抜粋部分も同等ならば）、整数拡張が入るケースを想定しなければならないためintにしておかなければならないという説は頷けます。
# JIS X3010 : 2003 では見つけられませんで、古い規格も見られないようなので裏は取ってませんけど。
## includeなしで標準関数使っても怒られないのは処理系の独自仕様だと思ってた

jacta · Answer

> 結局（charで表す事ができるはずの）'A'がcharなのかintなのか。

今までの回答では、誰もがみなintだと書いていると思います。
'A'のような単純文字定数はint、L'A'のようなワイド文字定数はwchar_tです。より詳しく知りたいなら、JIS X3010:2003の6.4.4.4 文字定数を参照してください。

> 　ここについての私の見解は、単純にこの関数を規定した人（たち）が「仮引数の型の決め方が理にかなっている」よりも「getchar()なんかで文字を扱う仮引数はintばっかりなのでこれもintで良いジャン」を優先させた結果じゃないかなと思う。

> そもそもここってC言語の規定じゃなくってCライブラリの設計理念の話だよね。
> 　いや、もちろん標準CライブラリうんぬんってのもC言語の言語仕様とともにどこかで規定されてるんだろうけど。

標準ライブラリはC言語の規定です。
詳しくは、JIS X3010:2003の7. ライブラリを参照してください。

> そういう意味では「(char *, int)だったらK&R仕様のコンパイラでも通るようになるじゃないか」と、ものすごく古いところまでの互換性まで考えてこうなったのかも知れないね。

C90では、可変個引数を持つものを除き、標準ライブラリ関数を関数原型（プロトタイプ）なしで呼び出してもよいことになっています。少なくともC90（というよりC89）が制定された時点では、世の中に存在する処理系は標準化以前のものばかりだったわけで、ものすごく古いという考え方は当てはまりません。
関数原型なしで、例えば、

char *strchr();
int main()
{
  char *p = strchr("abc", 'c');
  return 0;
}

のような使い方ができるようにするには、標準関数の仮引数はcharやshortでは駄目で、intでなければなりません。
C90に、floatを引数に持つsqrtfなどがないのも同じ理由からです。
# AMD1からは、wchar_tを取る関数があったりして、混乱が見られますが...

getcharやfgetcの返却型がintなのはEOFを表現できる必要があるからですが、strchrの第2引数がintなのはそんな理由ではないのです。
isalphaの引数がintなのも、EOFを表現できるようにというよりは、まずはintでなければならないからで、intならEOFでもよいことにしようというのは後付ではないかと思います。

> 「charであっても文字を全て表す事ができるとは限らない」は真にはならないでしょう。

漢字などの多バイト文字だけは例外ですね。

anmochi · Answer

うわ。伸びてますな。ううん・・・・本当は議論のようなレスの繰り返しはNGなんだけど、最終的な結論を出すためにあえて踏み込んでみたい。

> C++では'A'はchar型ですが、'AB'のような多文字リテラルはint型になります。
　便乗質問で申し訳ないけど、ここをすっごく知りたい。結局、今までの話の流れではC++ではどうだ、多文字ではどうだという話ばかりで「C言語の仕様において'A'という単文字リテラルがcharなのかintなのか」という事が正確になってない。これは是非専門家の方に解説していただいてやね。より正確で詳しいQ&Aになれば良いんじゃないかなぁなんて。C++の話はとりあえずおいておいて、"abc"などの文字列リテラルや'AB'などの多文字リテラルも省いて、結局（charで表す事ができるはずの）'A'がcharなのかintなのか。一応GCC 3.3.6 releaseではsizeof('A')=4になった事を報告しておきます。これは処理系依存じゃなくてきちんと規定されてる内容の実装って事で良いのでしょうかね？

> strchr() のように「文字しか想定していない」状況でも int 型が使用されているのが不自然に思えたので、今回質問させていただきました。
　ここについての私の見解は、単純にこの関数を規定した人（たち）が「仮引数の型の決め方が理にかなっている」よりも「getchar()なんかで文字を扱う仮引数はintばっかりなのでこれもintで良いジャン」を優先させた結果じゃないかなと思う。そもそもここってC言語の規定じゃなくってCライブラリの設計理念の話だよね。
　いや、もちろん標準CライブラリうんぬんってのもC言語の言語仕様とともにどこかで規定されてるんだろうけど。そういう意味では「(char *, int)だったらK&R仕様のコンパイラでも通るようになるじゃないか」と、ものすごく古いところまでの互換性まで考えてこうなったのかも知れないね。

　文字をcharで表す事ができるか否かについては、ANo.9さんに同意。文字を十分表す事ができる型をcharと定義する事とした、というのが正しくて、仮にワードマシンというものがあったとしても、それはバイトとワードが同一長になる（例えばcharもintも32ビットになる）だけの話で、命題「charならば文字を全て表す事ができる(←これはC言語の定義です)」の逆にも裏にも対偶にもなっていない「charであっても文字を全て表す事ができるとは限らない」は真にはならないでしょう。

　IA-32とか超得意分野。まず、レジスタで計算するのは当然の話で、基本的にはMOV命令→ADD系命令の繰り返しで計算していきます。いや、ADD系命令でメモリtoメモリという命令もあるんだけど、私はコンパイラの出力では見たことないと思う。この辺に関してはi80386(というかi8080)からP6まで何も変わってません。NetBurstやCoreマイクロアーキテクチャは分からないけど・・・・。
　で、IA-32の場合、ALレジスタ(8bit)、AXレジスタ(16bit)、EAXレジスタ(32bit)というものがあって(母体は同じ)、このうちcharからcharへの代入はMOV AL, mem→MOV mem, ALという命令になり、8ビットで動作している事が分かります。IA-32ではアドレッシングはワード単位にしないと効率が悪く(=命令処理ステップ数が多く)なりますが演算はバイト単位でも問題ありません。

　後、ごめんなさいANo.2の記述に誤りがありました。80x86のPUSH命令には8ビットで積む命令がありませんでした(出典：80x86/x87ハンドブック(ナツメ社))。MS-Cコンパイラの#pragma packコンパイラ命令(これは構造体の配置を制御する奴)と混同していたようです。なので、少なくともIA-16やIA-32において8ビットでスタックに詰まれるという事は無いようです。ただ、だからと言ってCコンパイラがintで積む訳ではないというのはお間違えなく。ん？　同じ事か？　ん～・・・・ここは専門家の意見を仰いだ方が・・・・。

　また、スタックポインタ(IA-32ではESPレジスタやEBPレジスタ)はレジスタは指しませんし、ワード単位でしか動けないという事はありません。でないとint v[10]; int *a=v[0]; a++;が実際はaが4増える(VC++4.0 32bit版以降)という理屈が成り立たないよね。char v[10]; char *a=v[0]; a++;が1増えるのでバイト単位の移動ができてるはずだもんね。

　あれこれ書きすぎて長文で申し訳ないね。

jacta · Answer

> 「文字」をメモリの中から区別して表現するためには char では足らない状況があったため、統一的に int を使っているのだと思う、と言うことです。

多バイト文字を除けば、文字を表現するのにcharで足りないという状況はありません。
JIS X3010:2003の6.2.5 型から引用すると...

 型charとして宣言されたオブジェクトは, 実行基本文字集合の任意の要素を格納するのに十分な大きさを持つ。実行基本文字集合の任意の要素をchar型のオブジェクトに格納した場合, その値は非負であることを保証する。その他の文字をchar型のオブジェクトに格納した場合, その結果の値は処理系定義とするが, その型で表現可能な値の範囲に含まれなければならない。

となっていることが理由です。

> char は 1byte ですが、マシンの最小処理単位が 1byte ではない環境（ワードマシン）があることが原因じゃないかな、と。

例えば、アドレスが16ビット単位の場合、charを16ビットとして実装するのが普通です。どうしてもcharを8ビットにしたい場合、char*はアドレスのほかにワードの上位か下位かを表すビット情報が含まれることになります。
つまり、これはcharで文字を表現できない理由にはなりません。

> まず 'A' が int と言うのは事実です。

これはその通りです。
C++では'A'はchar型ですが、'AB'のような多文字リテラルはint型になります。

> で、x + y がいったん int になる、と言うのは整数拡張のことを指していると思われます。（これは言語仕様としてはC99からかな？）

整数拡張というよりは「通常の算術型変換」によるものです（通常の算術型変換の過程で整数拡張が行われることがあります）。
整数拡張（integer promotion）という用語はC99のものですが、以前は汎整数拡張（integral promotion）という用語が使われていただけで、内容は同じです。

> が、x = y や関数の引数として char を渡したときに int に拡張される、というのは処理系依存だと思います。

処理系には依存しません。
ちなみに、x + yのときにintに拡張されるかどうかは処理系に依存します。なぜなら、charが符号無しで、charとintのビット数が同じ場合はunsigned intに拡張されるからです。

_himajin_ · Answer

#5です。

ちょっと書き方が足らなかったようで誤解されてしまったかな。
int にキャストされてしまうことが悪いのではなくて、「文字」をメモリの中から区別して表現するためには char では足らない状況があったため、統一的に int を使っているのだと思う、と言うことです。
char は 1byte ですが、マシンの最小処理単位が 1byte ではない環境（ワードマシン）があることが原因じゃないかな、と。

以降は結構怪しい蛇足。（間違っていたら指摘していただけると助かります）
#6 についてですが…まず 'A' が int と言うのは事実です。
で、x + y がいったん int になる、と言うのは整数拡張のことを指していると思われます。（これは言語仕様としてはC99からかな？）
が、x = y や関数の引数として char を渡したときに int に拡張される、というのは処理系依存だと思います。
# 正確には int と言うわけではないけど

たとえばIA-32のCPUだと演算にはレジスタを使いますが、このレジスタのサイズが32bitあるため、x = y は（実際には何も演算しないけど）y を演算用に一旦32bitに拡張してレジスタへ格納し、x にコピーするオブジェクトを生成することがあります。
関数に渡すときは引数をスタックに積むのですが、これも同様な理由でスタックを指すスタックポインタがレジスタしか指せない（？）ため、前述の理由で一旦拡張されます。
と言うわけで、実際の動作としてそうなることはあるが、それは言語として決まっているのではなく、マシンに対応するために処理系がそうしているだけ、と思うのです。

jacta · Answer

> x=yも、yをintに拡張してその下位1バイトを取ってxに代入します

そんな仕様はありません。
JIS X3010:2003の6.5.16.1 単純代入から引用すると...

意味規則　単純代入（simple assignment）（=）は, 右オペランドの値を代入式の型に型変換し, 左オペランドで指し示されるオブジェクトに格納されている値をこの値で置き換える。

となっています。
char x, y;に対して、sizeof(x = y)が1であることから、代入式の型がchar型であることは明白です。つまり、intを介さずに直接charに型変換されることになります（この場合は、同じ型なので変換なし）。

> つまり、Cでは関数にchar型の値を渡すことは不可能で、自動的にintになってしまいます。それを受ける仮引数もintの必要があると言うことです。

そんな仕様もありません。
同じく6.5.2.2 関数呼出しから引用すると、

実引数は, 任意のオブジェクト型の式でよい。関数呼出しの準備の段階で, 実引数を評価し, 各実引数の値を対応する仮引数に代入する。

となっています。代入の際に、無意味なintへの変換がないことは上述の通りです。
ただし、関数原型がない場合は話が別です。

notnot · Answer

＞>Cの場合は、charの値というのは書いた瞬間にintになりますので

他の方の回答で解決したのかもしれませんが。以下、Cの場合です。
まず、char型の定数はありません。'A' はint型の定数です。これはいいですよね。
char x,y; とすると、 x+y という式を書くと、xがintに拡張されて、それとyがintに拡張した値と足します。
x=yも、yをintに拡張してその下位1バイトを取ってxに代入します(コンパイラは最適化したコードを出すのでこうはならないですが、理論上こういうことです)。

つまり、Cでは関数にchar型の値を渡すことは不可能で、自動的にintになってしまいます。それを受ける仮引数もintの必要があると言うことです。

_himajin_ · Answer

#2に概ね同意です。
c = getchar();
if (c != EOF)
p = strchr(buf, c);
のような連携が楽だからでしょう。

背景として char は「文字」ではなくて「文字を入れるのに十分なサイズを持った整数」であることとか、char が signed / unsigned どちらなのか処理系依存なこととかがあって、何かの中から文字を区別するためには int を使う慣習になっているのだと思います。（それが char で十分である場合も、そうすることで無用な型変換を避けられる）
# is*** 系が int なのは unsigned char と EOF をカバーする必要があるためです。

参考URL：http://www.opengroup.org/onlinepubs/009695399/

jacta · Answer

#3です。

> 第2引数は自動的に int にキャストされてしまうので、
> どうせキャストされるんだから strchr(const char*, int); でいいっだろう。

「～でいいだろう」ではなく、「～でなければならない」です。
実引数の型と仮引数の型が矛盾する場合の動作は未定義ですから。

strchr() の第2引数はなぜ int 型なのでしょうか

C++やC99では関数を呼び出す際には関数原型が必須ですが、以前の規格では可変個引数を持つもの（printfなど）を除けば、標準関数は関数原型なしで呼び出してもよいことになっていました。

またしても無駄な蛇足が増えて必要な補足が足りず、、、すみません。

> 結局（charで表す事ができるはずの）'A'がcharなのかintなのか。

うわ。

> 「文字」をメモリの中から区別して表現するためには char では足らない状況があったため、統一的に int を使っているのだと思う、と言うことです。

#5です。

この回答への補足

> x=yも、yをintに拡張してその下位1バイトを取ってxに代入します

＞>Cの場合は、charの値というのは書いた瞬間にintになりますので

#2に概ね同意です。

#3です。

似たような質問が見つかりました

関連するカテゴリからQ&Aを探す

デイリーランキングこのカテゴリの人気デイリーQ&Aランキング

マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング

　うわ。