("break"と2)を検索しています。0;}実行結果例は以下となります。(NULL?)が表示されていることがわかりました。マッチ自体はうまくできているようにみえます。検索結果のentry2からきちんと参照できています。先の質問で以下の通り,たまたまうまくいっているだけとの指摘をいただきました。あなたのコードではポインタの内容の4または8バイトの内容をstrcmpで比較してしまっています。ポインタそのものを表すバイトの途中に0x00が現れれば、誤った結果を出すでしょうし、逆に0x00がどこにもない領域に配列が置かれていたら、メモリ未割り当ての領域アクセスで異常終了するかもしれません。そこで,2点の質問です。配列のtab1とint配列のtab2の検索でうまくいかない具体的なパターンを教えてほしい。float/double)の検索を実現したい。(文字配列はstrchr単独で検索可能なため除外)。片方だけの回答でも歓迎です。配列のtab1とint配列のtab2の検索でうまくいかない具体的なパターンを教えてほしい。*まずは、こちらの後半の質問にお答えしておきます。int用のテストコードをこちらのように修正して実行して見てください。FOUND");}実行結果はこんな風になるはずです。0x7ffeefbff5dc:256lfindによる検索結果はkey2の値に一致する2個目ではなく、1個目の256だと出力されています。これはint型の数値の256や512がどのようにメモリ中に保存されているのかを考えるとわかります。endianで示しています。|0x00|0x02|0x00|0x00|strcmpは引数のポインターから、NUL文字、つまり0x00となるまでの範囲を比較するのはご存知かと思います。したがって256が格納された領域の先頭アドレスと512が格納された先頭アドレスにはどちらも先頭に0x00、NUL文字が入っていることになるので、そこで比較が終わってしまうのです。result);resultの値は、「等しい」を表す0になるはずです。"")の結果が0になるのと同じなんですが、お分かりでしょうか。*の場合は、ポインターで、ポインターそのもののアドレス値が特定のビットパターンになるようにするのは難しいのですが、ポインターの実態は単に整数値で0x7ffe40601408だとか、0x7ffeefbff5e0とか言った中身になっているのは%pの出力でお分かりでしょう。2つのポインターが0x7ffe40601400と0x7ffeefbff500なんてアドレスになっていたら、上記の256と512と同様に全体としては全然違うアドレスだけど、strcmpが等しいと判定してしまうと言うことが起こり得ます。ここでは例を簡単にするために最下位の1バイトが0x00になるような例を作りましたが、もちろん最下位以外のどこかのバイトが0x00でそこまでは全バイト等しい、なんてアドレスの比較でもstrcmpは「等しい」と判定してしまうでしょう。(例えば、0x7ffe40600014と0x7ffeefbf0014を上のaとbに入れてみてください。array版では、ポインターのアドレス値同士をstrcmpで比較してしまっているので、「アドレスは違っているけど、ポインターの指す先にある文字列は同じ内容」と言う場合にも所望の動作をしなくなります。float/double)の検索を実現したい。(文字配列はstrchr単独で検索可能なため除外)。私的には、「できれば自前での比較用関数の実装は避けたい」なんてことにこだわるよりも、比較関数の定型的な書き方をさっさと身につけた方が良いのではないか、と言うところです。int型の比較を行う正しいコードはこんな感じになります。0x7ffeefbff5e0:512と言った感じになるはずです。左の方が小さければ負の値、等しければ0、そうでなければ(左のほうが大きければ)正の値を返すと言う処理を書くだけです。出てくる処理を書くために(下手すると自分で専用処理を書くのと大差ない長さの)比較関数を書かないといけないと言うのは、ある意味C言語の制約上仕方ないと言ったところでしょうか。(ちなみにcmpare_int関数はlfind専用でよければもう少し簡略化できますが、bsearch等に使えなくなってしまうため、そちらのコードは掲載しないでおきます。)この辺をしっかり身につけてからテンプレートやらジェネリクスやらのある言語をやると、その便利さがよくわかるかもしれません。渡せる保証は無いので(まあ99.9%以上の処理系で問題ないが)オイラなら別の書き方をするでしょう。23:20詳細なご解説ありがとうございました!型の合っていない引数でstrcmpを使ったため,アドレス同士の意図しない比較となってしまったと理解しました。検索対象に,strcmpを使った例がありました。キャストやポインターが絡む場合,型に注意するようにします。lfindの使い方の勉強中に,こちらで見つけました。bsearchの比較関数の要件も,一致したとき0,他は正か負なので,このワンライナーでも問題なさそうです。OOPerさんが意図した簡略関数と,こちらの予想が違うのかもしれません。さん、ご名答、その関数が私が「簡略化」として意図していたものです。(-1000000000)を計算してみてください。(0はどちらもちょうど9桁。)前が正、後ろが負ですから比較関数の結果として使うには、「前が大きい」を表す正の値が返らないといけないのですが、値は-1294967296なんて負の数になってしまいます。32bitの整数減算がオーバーフローしてしまっているのが原因なので、「絶対に(intのサイズで)オーバーフローするような値はでてこない」と言う場合にしかbsearch用には使えないと言うことになります。12:21帰宅して確認しました。(false)になりました。今まで,そこまで精度や型など細かく気にしていなかったので,たいへん参考になりました。|回答スタック・オーバーフローに参加してくれて、ありがとうございます!質問の回答を共有してください。回答を説明し、自分の検討結果も共有してください。意見を述べること(意見を述べるなら、参照リソース、自分の経験で意見をサポートしてください)さらにサポートが必要な場合このヘルプを参考してください。“回答を投稿”をクリックすることで利用規約、プライバシーポリシー、及びクッキーポリシーに同意したものとみなされます。タグが付いた他の質問を参照するか、自分で質問をする。実現したい5C言語でPOSIX規定関数のlfind関数で配列要素にマッチした文字列の参照方法0プログラムがうまく起動しません。質問のフィードこのRSSフィードを購読するには、このURLをコピーしてRSSリーダーに貼り付けてください。