アカウント名:
パスワード:
void die(e,s) int e; char *s; { substdio_putsflush(subfderr,s); _exit(e); }
void straynewline() { out("451 See http://pobox.com/~djb/docs/smtplf.html.\r\n"); flush(); _exit(1); }
if (databytes) if (!bytestooverflow) { out("552 sorry, that message size exceeds my databytes limit (#5.3.4)\r\n"); return; }
順もさることながら、不要になった時点で評価を止めてしまうというのも大事です。 たとえば if (x1 && y) で x1 が偽の場合、if (x2 || y) で x2 が真の場合などでは、y は評価されません。
こういう仕様最近ではあたりまえですが、C言語以前では、最後まで必ず評価されてしまうものや評価されるされないが実装でバラバラなので「されてしまう」ことを前提にコーディングしなきゃいけないもの、なんてのがゴロゴロしていました。なので、この部分を明確にしていた Cという言語は私には画期的に思えたものです。
難読プログラムコンテストにでも出す気なのか?
DJB は IOCCC Winner [ioccc.org] です。
実はコードがあまりにアレなので、バグの検証をしようという人がいないから長期間バレてないってだけだったりして。
今やSMTP-AUTHやv6やTLSへの対応などの機能拡張が必須に近くなっているのに、djbはまったく対応しようともしない
まぁ,djb 先生は IPv6 に否定的 [cr.yp.to]みたいですから,v6 patch が必要な状態はまだまだ続くでしょう. # 個人的には我が家に IPv6 のアドレスがちゃんと配られることをまず希望.
if (dns_domain_equal(d,"\0011\0010\0010\003127\7in-addr\4arpa\0")) {
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
qmailのソースが (スコア:3, おもしろおかしい)
ちらっと見てみたら確かにすごい!!
適当に開いてみたtcpto.cの96行目当たりから
lastwhen = (unsigned long) (unsigned char) record[11];
lastwhen = (lastwhen << 8) + (unsigned long) (unsigned char) record[10];
lastwhen = (lastwhen << 8) + (unsigned long) (unsigned char) record[9];
lastwhen = (lastwhen << 8) + (unsigned long) (unsigned char) record[8];
when = now();
プログラミング初心者の私がいうのも何なんですが
よくこんな書き方で穴がないもんだ…。
マジックナンバーのオンパレードだし、コメントはさっぱりないし。
作者は天才なんだろうなぁ。
その他の例 (スコア:3, 参考になる)
例えば、qsmhook.cの
とか。なんでこんなにしてまで1行にしなきゃいけないんだろう。
難読プログラムコンテストにでも出す気なのか?
これ(qmail-smtpd.c)なんて
読みにくいのもそうだけどサイトのURLが変わったらどうすんのよ。
それだけでバージョンアップ?
他に気になる点は
databytes関連で、こんな個所もありました。
複数のif文まで1行ですか。はあ。
--------------------
/* SHADOWFIRE */
英語が母国語の人は (スコア:2, 参考になる)
日本人から見ると、構造化もへったくれもないただの汚いコードにしか見えない、ということなんだよ。
だから、このコードを英語があまりうまくない日本人が書いたとしたら、批判は当たりと思うよ。
Re:英語が母国語の人は (スコア:0)
ヨタ話とか思えないけど、もし本気で言っているのなら、論理記述言語と
自然言語についてもうちょっと勉強したほうがいいと思うよ。
COBOLって好きさ! (スコア:0)
Re:COBOLって好きさ! (スコア:0)
ヤシがいる場所だよ、ここ。
Re:その他の例 (スコア:2, 興味深い)
if( x ) if ( y ) { ... }
って if( x && y ) { ... }
と同じじゃないんでしょうか(マクロで書くなら気をつけなきゃいけませんが)。
スタンダードではないですがある意味深いカッコがへっていいような気もするので、少なくとも「スタンダードでないからダメ」以外の理由でそんなに理に叶っていないとか特別に読みにくいコードには見えないです。
# でも僕は決してif( x ) if( y ) なんて書きませんよ
脆弱性発見とかいうトピックで、こんなにソースを見ている人がいるのかと思ってびっくりです。
---
飲酒済みにつき乱筆御容赦。
Re:その他の例 (スコア:1)
Re:その他の例 (スコア:0)
> って if( x && y ) { ... }
> と同じじゃないんでしょうか(マクロで書くなら気をつけなきゃいけませんが)。
上のコードではxの評価が必ずyの評価よりも先になります。下の場合はどちらの評価が先になるか分かりません。
Re:その他の例 (スコア:0)
if (p && p->x) { ... }
と書けないことになるじゃないですか。
Re:その他の例 (スコア:1)
>と書けないことになるじゃないですか。
C言語の場合,
結合規則(?)で「 x && y && z は, ( x && y ) && z と評価する.」とはあるけど,
「 && は,左オペランドを先に評価する.」と決まってました?
# if( x ) if( y ) { ... }
# と書けば,必ず x が先に評価されてから y が評価されるので,
# 評価の順番が明確になります.
Re:その他の例 (スコア:0)
> C言語の場合,
>結合規則(?)で「 x && y && z は, ( x && y ) && z と評価する.」とはあるけど,
>「 && は,左オペランドを先に評価する.」と決まってました?
決まっている [catnet.ne.jp]らしいですね。
まあ、私的には書き方なんてどうでもいいと思いますが。
Re:その他の例 (スコア:0)
Re:その他の例 (スコア:1)
&& || ,(カンマ) と ?:(3項演算子) は,特例か...気をつけないと.
Re:その他の例 (スコア:1)
順もさることながら、不要になった時点で評価を止めてしまうというのも大事です。 たとえば if (x1 && y) で x1 が偽の場合、if (x2 || y) で x2 が真の場合などでは、y は評価されません。
こういう仕様最近ではあたりまえですが、C言語以前では、最後まで必ず評価されてしまうものや評価されるされないが実装でバラバラなので「されてしまう」ことを前提にコーディングしなきゃいけないもの、なんてのがゴロゴロしていました。なので、この部分を明確にしていた Cという言語は私には画期的に思えたものです。
Re:その他の例 (スコア:0)
そのためのpobox.comなんじゃなくて?
# まあ、pobox.com自体が消滅する、という可能性もないわけではないが。
Re:その他の例 (スコア:0)
Makefileに書くなり、djb的文法でもconf-hogehogeっていうのも
あるのに。
難読プログラムコンテスト (スコア:0, 参考になる)
DJB は IOCCC Winner [ioccc.org] です。
Cは文学だねぇ (スコア:2, フレームのもと)
で、「ここではこんなことを大切にして書く」というところが重要で、その「大切にしてるもの」が、そのコードでなぜ大切なのか?ということにちゃんと理由があるわけ。自分の書いたコードや自分が大切と思っていることしか強調できない「コドモ」は、所詮その程度のプログラミングの能力しかないんだよね。経験上、だけど。
ハードウエアの動きも頭の中でちゃんとできていて、それを考慮に入れたこの人のコードは、出来の良い文学の1つを読むみたいですよ。その文学が気に入るかどうか、ということとは別にね。
だから、今でもなかなか穴がみつからない完成度の高さを持っているわけで。
物事を自分がいま見える方向からだけ見て評価して、それを絶対と思っちゃだめよ。コードを通してその人の考えていることや人柄やコードを書いたときの体調まで見通せるくらいにならないと。
精進してくらはいね。
Re:Cは文学だねぇ (スコア:2, おもしろおかしい)
なるほど。俺がなぜいつまでたってもダメプログラマなのか
やっと分かりました。
プログラミングの勉強する前に、プロファイリングを
修めてきますよ。
良いプログラムに見えます (スコア:1)
ほとんどのCPUアーキテクチャで正しく動作する
良いプログラムに見えます。
エンディアンの問題とかメモリーのアクセス制限に引っかかることも
なさそうで、良く考えて作ってるなと思いますよ。
Re:良いプログラムに見えます (スコア:2, 参考になる)
うーん、そうですかねえ。プログラミング/アルゴリズムのお勉強の初歩の初歩、総和の計算を思い出してしまいました。sum=5+4+3+2+1というの。
DJBはライブラリ関数を信じないそうで、qmailにはその代替のサブルーチンを大量に含んでいます。だけど、微妙にライブラリ関数と引数並びが異なったり、中で初心者がやりそうなコードがあったりと、あまり人様に見せて誇れるコードでは無い様な。#476402のAC氏も述べているコンパイル時に警告が多発するのも、オーソドックスなコード書きからは外れてますし。
Re:良いプログラムに見えます (スコア:0)
多少クセがあって素人くさい不思議なソースで脆弱性がないもの
どっちがいいの?
なんくせ付けてる人はさぞ綺麗で脆弱性がないソース書きの人なんだろうね。
Re:良いプログラムに見えます (スコア:2, すばらしい洞察)
> くさい不思議なソースで脆弱性がないものどっちがいいの?
それは、尾籠な話ながら、固形の排泄物味のカレーとカレー味の固形の排泄物のどちらが食べたい?な質問ですね。
そのどちらもヤ!がボクの答、カレー味のカレーが良いですし、綺麗で脆弱性が無いのが良いでしょう。綺麗である事(論理構造がはっきりしていて読み易い、実行速度とオブジェクト量のバランスが取れている)事と脆弱性が無い事とは、相反する概念ではありませんよ。
# 綺麗だと検証が楽ですしね。(笑)
Re:良いプログラムに見えます (スコア:0)
いろいろ書けるんですが、読めない奴が読めないといってしまうとそれは綺麗なつもりでもそうではないコードになってしまう・・・。
Re:良いプログラムに見えます (スコア:1)
qmailも…うーん。ソースをいじったことはあるんですが、書き方よりも独自Cライブラリのなれの問題かもしれません。
ライブラリを自分で追ったことがあるんですが、あれは割と苦行でした。
# 関数の実体を作るマクロ、こまごました(古い)最適化、ループの展開etc…
よくこれでバグなく動くなぁというのと作者が天才なんだろうなぁというのは僕も同感だったりします。
Re:良いプログラムに見えます (スコア:0)
実はコードがあまりにアレなので、バグの検証をしようという人がいないから長期間バレてないってだけだったりして。
Re:良いプログラムに見えます (スコア:1)
もしかして信者の方かな?
(素でそんなこと言ってるとしたら怖い)
まあ、付け加えるなら「メンテナンス性」は大事だよ。
可能な限り綺麗で脆弱性がないソースを書くのが理想。
無理ならコメント等で可読性を上げるのも手段の一つ。
人に説明するのが上手な人ほど物事の本質を捉えるのが上手。
それができないのは「オレ様が分かればOK」な思想の産物だし。
(まあ、大体はそれは「分かってない」ことと同義なんだけど)
Re:良いプログラムに見えます (スコア:0)
という話なのにどうしてそういう反応になるの?
誰が難癖つけているの?
Re:qmailのソースが (スコア:1, すばらしい洞察)
フリーソフトって素人臭いコーディングが非常に多いんだけど、qmailって群を抜いてへんてこなコーディングなんだよねえ。悪いコード例、「絶対にこんな書き方をしてはいけない」の強力な実例として引き合いに出される場合もけっこうあったりして。
# まあ、うごきゃ良いってのはそうなんだが、
# このD. J. Bernsteinって人は、教育者だった事 [cr.yp.to]も
# あったりするんだよね。
Re:qmailのソースが (スコア:0)
悪いコード例かどうかはともかく、「普通じゃない」のは確かだ。
Re:qmailのソースが (スコア:0)
ソフトウェアではないような気がするので、へんてこなコーディング
でも問題ないんじゃないでしょうか。自分が書いたコード以外
を信じないような人な
Re:qmailのソースが (スコア:2, 興味深い)
いるのに、djbはまったく対応しようともしないので、結果パッチが乱立。
というわけで、djbにオーソライズされていないコードを利用せざるを
得ないのでは、セキュリティの確保とは正反対の方向に行っています。
また、各パッチを矛盾なくうまく当てようとするにはコードを読む必要が
あるのにもかかわらず、あのコードは…。
Re:qmailのソースが (スコア:1)
まぁ,djb 先生は IPv6 に否定的 [cr.yp.to]みたいですから,v6 patch が必要な状態はまだまだ続くでしょう.
# 個人的には我が家に IPv6 のアドレスがちゃんと配られることをまず希望.
Re:qmailのソースが (スコア:1, 参考になる)
エンディアンに左右されずに4bytesな整数を扱いたいだけですよね。
Cで書けばこんな表現日常茶飯事のような。
# 関数使え or マクロ定義しろ って話?
最近はJavaしか知らない方が増えているらしいですけど、
そんな方から見ると、確かに異様なのかもしれませんが……
Re:qmailのソースが (スコア:0)
単純にそう思いました。
職人技が多数盛り込まれててすごいですよね。
元コメントも別に嫌味ではないつもりです。
驚きの世界があるなぁ、というだけで。
Re:qmailのソースが (スコア:2, すばらしい洞察)
素人が職人技を見てもそれがすごいことだとは必ずしも解らない、というのはプログラミングに限った話ではないとは思いますが、自分が使えればいいだけの職人技は後継者がいなければ廃れていきます。
それの何がすごいのか、他の方法の何がいけないのか、それを習得するための方法などがわかりやすく整理されていないことが、良いものではなく普及したものが残っていくということに拍車をかけているのだと思います。
Re:qmailのソースが (スコア:1, 参考になる)
コンパイルすると警告でまくるしね。
Re:qmailのソースが (スコア:1, おもしろおかしい)
Re:qmailのソースが (スコア:1, おもしろおかしい)
Re:qmailのソースが (スコア:1, 興味深い)
なpatch当てが必須なのにも関わらずこういうコード。なのでdjbなコード
を見てなんじゃこりゃ~と嘆く人が増えるんだろうなぁ。ライバル(というと
なんだけど)のWietse Zweitze Venema氏のコードと比較しちゃうとなおさら…。
Re:qmailのソースが (スコア:1, 興味深い)
美しかったり面白かったりするソフトウェアを思いつく人は教えてほしいなー。
難解Cプログラムコンテストは面白い。けど、逆方向で。
すばらしく明快なソース (スコア:0)
# 茶々以上のなにものでも無いのでAC
Re:qmailのソースが (スコア:1, 興味深い)
qmailのソースの各ファイルは小さいから簡単に修正すべき
場所を見つけられていいぜ。
メンテが面倒ってのはわからんなあ。MTAって一度設定したら
メンテ必要なのか?そんなにメール環境がよく変わるのか?
DJBツールの設定は確かに独特だけどね。おまけにmanが
わかりにくいからね。けど、一つの設定ファイルに色々な
設定項目をだらだら書くよりも良い方法だと思う。
Re:qmailのソースが (スコア:0)
昔、Sendmailが8.9.1の頃、MUA側のMIME処理の問題 [cert.org]で8.9.1aというpatch [impress.co.jp]が出たのですが、こいつには"Content-Transfer-Encoding" fieldが増殖するというbugがありまして、泣く泣くSendmailのコードをhackしたことがあります。
その過程で、とりあえず版を作って動かしてみたら、multi-partのメールを処理する際に、body内の"Content-Transfer-Encoding" fieldを削ってしまうものが出来ていしまいました。
慌てて、再度hackして一応まともに動くものが出来たのですが、その成果をSendmail.orgに報告したら、「この修正はいまいちなので、こっちのpatchを使ってね。」と"とりあえず版"と全く同じpatchが送られてきて、、、
Re:qmailのソースが (スコア:0)
高ければもっと解析も修正も早いでしょう、といってみる。
# でもPostfixあたりには負けて欲しくないのでAC