「Linux、2003年にバックドアを仕掛けられそうになっていた」記事へのコメント

C が悪い(フレームのもと)

[Anonymous Coward]

if((...) && (uid = 0)){}
これを 0 == uid 以外だめってことにすればいいんじゃない?
というか eq とか subst とかいうマクロにしたらどうだい?

Re:

[Anonymous Coward]

本家には wait4: 'if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) ...' と書いてますね。なんで日本語だと本文に無いんだか。

で、これだと代入が括弧で囲まれてるから警告出ないと。確かにcurrent.uid == 0だと括弧要らないですが、&&の右辺だと括弧入れるコーディングスタイルの人も多いから厄介ですね。それもあって単なるうっかりミスかもしれないとも言われてました（ちゃんと議論追ってないので良く分からないですが）。

この場合だと二重括弧じゃないと警告出すようにすれば良いとも思うのですが、しかし色々と一貫性を考えてみるとそもそもCの構文が悪い気もする。

Re:

[Anonymous Coward]

> 色々と一貫性を考えてみるとそもそもCの構文が悪い気もする。

つまり、「=」が代入で「==」が比較というCの定義が悪いということだと思います。
あるいは、代入を構文ではなく演算子だとしてしまったために、式が書けるあらゆる
ところで代入が可能になってしまったのが悪いということでしょうか。

たしかに、Cの基本設計（代入は演算子なので、本来、ifの条件式の中でも代入が
できるべき）を認めた上で、かつ今回のような問題を防ぐには、小手先の小細工になって
しまうし、一貫性を失って奇妙なことになる（カッコで囲まれていたら警告を出さないとか）
と思います。

だったら、Cでその定義は今更変えられないから、新しい言語を作って、
BASICみたいに「=」は演算子じゃないことにしてしまうか、
FORTRANみたいに比較は「eq」とかを使うようにするか、
Pascalみたいに代入は「:=」で比較は「=」にするか、
でも、C式の定義がC以外にも広く使われてるし、かえって混乱を招くかもしれません。

Re:

[Anonymous Coward]

代入が式であることが問題で、記号はどうでもいいでしょう。
あとは条件式がbool以外を取れることが問題です。
言語仕様を変えなくても、コンパイラがそれをチェックして警告を出すことは可能だと思いますよ。

Re:

[Anonymous Coward]

しかし、この場合、条件の値が0なので、もしそんな警告が存在すれば、NULLやFALSEを0と定義している場合、全て警告を出されてしまうので、到底実用的じゃないと思う。

言ってるように、括弧が付こうがなんだろうが、代入を式として評価しない方がいいし、それで十分だろう。

Re:C が悪い(フレームのもと)

[Anonymous Coward]

括弧付き代入の警告も、既存のプログラムだと警告が結構でるかもしれないと思ったので、
その点はあえて目をつぶりました。警告はOFFにできるしね。

Cじゃない別の言語を作る話なら、bool以外取らないという解決策の方が個人的には良いと思う。
代入式がそこら中に書けるのはシンプルで分かりやすいコードにできる方法だと思う。
代入1つのために中抜けループとか作りたくないし。

Re:

[Anonymous Coward]

> Cじゃない別の言語を作る話なら、bool以外取らないという解決策の方が個人的には良いと思う。

if ((count < MAX) || (f = true)) {
のようにbool型の変数へ代入してしまうバグは残る（作れる）ので万全とはいいにくい気が

# さらにboolの比較演算子をなくせばいいかな？
# if (!is_not_support() != false) みたいなコードもなくなるし

> 代入1つのために中抜けループとか作りたくないし。

while (c = getchar() ; c != EOF) {…}
のようにかければ、ほかは「代入文」でもなんとかなりません？

個人的には「代入文」（もしくは代入演算子の戻りをvoid）にして整理したほうが学習コストもバグ発生率も下げられるのでは？と思ってます

Re:

[Anonymous Coward]

#2476303 ですが、私が考えてたのは、代入が式として扱えることには何ら異論はなくて、
exp1 && exp2は正当なのに、if exp hogeと書けないのが変だなということでした。

&&のような条件演算子だって短絡評価を使えば実際if文に近い使い方はできるのに、左右に表れる式に括弧をつけなくても問題ない。ただし、自主的に括弧をつける人も多い。
一方、if文だと式に必ず括弧をつける必要がある。
で、代入文を括弧で囲わないと式として扱わない（警告を出す）ようにした場合、if文だとコード上は二重の括弧で囲われた形になるのに対し

Re:

[Anonymous Coward]

&&のあとだとどうだとか、二重括弧がどうだとか、
こんなにややこしいことを考えないといけないのなら、
いっそのこと、代入を式として扱えることを放棄してしまったほうが単純明快なのではと思います。

ひとつで複数の副作用を起こせる文（あるいは式）が存在する、ということそのものが、
人間のすなおな理解を超えているんじゃないかと思うのです。
（べつに、人間の理解力を超えていると言いたいわけじゃないです。
疲れてるときとか、うっかりとか、そういうときにミスが出やすいポイントだと思います）。
というわけで私は #2476486の意見に賛成です。