「m68k用Linuxに実装されたstrcmp()のコードにバグ。12年間気がつかず」記事へのコメント

ソート順がおかしくなるってことね

[Anonymous Coward]

まあ68kでバリバリ非ASCII文字使うことないだろうからまあいいんじゃないっすかね。

Re:

[Anonymous Coward]

strcmp()は2つの機能があって
- 文字列の一致不一致の判定
- 大小の比較
ができるけど、後者にバグがあったってことですね。

バグが出る条件は
- m68k
- 不一致の文字が非ASCIII文字の場合
で、 カーネル内部では大小の比較なんてめったに使わないし、そもそも m68k なんて誰も使ってない。

12年間も誰も気が付かないというか、12年間だれもつかってなかった、ってところでしょうね。

Re:

[Anonymous Coward]

複雑な挙動のテストケース漏れは仕方ないと思うけれど、こんな標準関数レベルですらテストコードが不十分だったんでしょうか。
このくらい基本的なテストコードなら、アセンブラでもアーキテクチャ依存でもなく共通で使いまわしができると思うのですが。

Re:

[Anonymous Coward]

元記事を読んでみた。

馬具は、アセンブラじゃなくて、asmを呼び出してるCのコードとの兼ね合い。
アセンブラは正しく実装されていて結果を符号付き8-bitで返している。なので、
負の値を返すには(カーネル内の問題となったstrcmpの戻り値の型がintだから)符号拡張しなければならんのだが、Cのコードは、このレジスタをcharで受けている。
charとだけ書くと、unsigned かsignedか決まっていなくて、処理系ごとにどちらかに決まる。
m68kで使っていたコンパイラはsigned扱いだったのね。なので、結果の8-bit目が1だったら、符号拡張されて、負の値がちゃんと返っていた。
そこに、コンパイルオプション-funsigned-charを追加したものだから、charはunsigned charと解釈され、char->ssize_tの変換で符号拡張しなくなって、負の値を返さなきゃならないときにも正の値が返るようになってバグが覚醒したと。

Re:ソート順がおかしくなるってことね

[Anonymous Coward]

見方によっちゃコードのバグではなくビルド設定のミスだな……
signed charとして扱う責任をビルド設定に持たすか各コードに持たすか

charの符号有無とかビルド設定切り替えるときは影響範囲確認せぇやって話だな

個人的には符号なしはbyte的な形で扱えば済むからcharは符号付きのが楽な気がしないでもない
でもis系関数相手だと符号無しのが楽よな……うーん