アカウント名:
パスワード:
pledge は流行ると思いますか？
まず pledge がどういうものかを説明します。プログラムって、最初は設定ファイルを読んだり一時ファイルを開いたりするけど、その後メインループに入ったら権限を殆ど必要としないことが多いですよね。だから、 コマンドラインオプション等に応じて [openbsd.org] メインループ直前で権限を落とすという仕組みなんです。
だから最初は tame (調教する [openbsd.org]) という名前の関数でした。獰猛な野獣 (いったん任意のコマンド実行を許す脆弱性があると何でもできちゃう) を手なずける (脆弱性があっても殆どのシステムコールが実行不可能) という感じですね。
現在では主語が変
> tame(TAME_STDIO | TAME_CMSG | TAME_GETPW | TAME_PROC | TAME_DNS, NULL);>というインターフェースにするのが普通の発想じゃないかと思うんですが、この pledge は> tame("stdio cmsg getpw proc dns", NULL);
後者の方が，今風のAPIだと思います
理由は３つ
1) 後者のほうが短い(≒可読性も高い)
古典的なC言語だとtame(TAME_STDIO | TAME_CMSG | TAME_GETPW | TAME_PROC | TAME_DNS, NULL);はよく見かける記述ですが，これ冗長だと思いませんか？
2) 今時のCPUは高速なので，文字列処理は大したオーバヘッドにならない
特に tame() は頻繁に実行する処理ではないので，文字列処理のオーバヘッドはあまり問題になりません
3) 文字列のほうが拡張性・保守性が高い
カーネルのAPI/ABIでは，将来的な変更・修正が少ないことも重視されます
ヘッダで定数のORを取る方針だと，たとえば64bit整数だと最大64個しかオプションが定義できません．65個目のオプションが必要なった場合は API/ABI を追加，または変更しなければなりません．そのため細かい制御には不向きであると言えます
一方文字列で指定する方針だと，API/ABIを保ったまま柔軟な拡張ができます．たとえばtame("get*", NULL);tame("getpw[uid==1000]", NULL);などです．
この手の拡張は，定数でOR作戦だと実質無理です．
個人的には，３番目の理由だけで，私は定数をORで指定する方式は選択肢にさえなりません
ですねぇ。加えて言うと、文字列なら他の言語との親和性も高くなりますしね。ヘッダファイル等での余計な定義も不要になりますし。
それでも文字列はないな。考慮しなきゃならないケースが無駄に多くなりすぎる。それはバグの温床だし、すなわちセキュリティホールの温床にもなりうる。それに理由3は割と簡単にあとから拡張可能だしね。
文字列の方が拡張性が高いのはわかるんですが、保守性も高いんでしょうか？
プリコンパイルやリンクでチェックやリンクできずにエラーになるならいいと思うんですけど、実行時にしかエラーがわからなさそうなものってどうにも抵抗が…（javaや.NETのリフレクションで文字列指定するのとかも抵抗があるんですよね。あっちはIDEのリファクタリング機能の対象外になるのも敬遠したくなる所以ですが）。
優秀なIDEがあればコードtypoなんかは警告だしてくれそうですが、それもあるかどうか不明ですし。実際に作る時はマクロでもつかってそのあたりの不安を埋めてくんでしょうかね？
# 最近jsばかり書いてるせいか、どうせ文字列つかうなら文字列テーブルにすればいいのにとも。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
pledge (スコア:5, 興味深い)
pledge は流行ると思いますか？
まず pledge がどういうものかを説明します。
プログラムって、最初は設定ファイルを読んだり一時ファイルを開いたりするけど、
その後メインループに入ったら権限を殆ど必要としないことが多いですよね。
だから、 コマンドラインオプション等に応じて [openbsd.org]
メインループ直前で権限を落とすという仕組みなんです。
だから最初は tame (調教する [openbsd.org]) という名前の関数でした。
獰猛な野獣 (いったん任意のコマンド実行を許す脆弱性があると何でもできちゃう) を
手なずける (脆弱性があっても殆どのシステムコールが実行不可能) という感じですね。
現在では主語が変
Re:pledge (スコア:1)
> tame(TAME_STDIO | TAME_CMSG | TAME_GETPW | TAME_PROC | TAME_DNS, NULL);
>というインターフェースにするのが普通の発想じゃないかと思うんですが、この pledge は
> tame("stdio cmsg getpw proc dns", NULL);
後者の方が，今風のAPIだと思います
理由は３つ
1) 後者のほうが短い(≒可読性も高い)
古典的なC言語だと
tame(TAME_STDIO | TAME_CMSG | TAME_GETPW | TAME_PROC | TAME_DNS, NULL);
はよく見かける記述ですが，これ冗長だと思いませんか？
2) 今時のCPUは高速なので，文字列処理は大したオーバヘッドにならない
特に tame() は頻繁に実行する処理ではないので，文字列処理のオーバヘッドはあまり問題になりません
3) 文字列のほうが拡張性・保守性が高い
カーネルのAPI/ABIでは，将来的な変更・修正が少ないことも重視されます
ヘッダで定数のORを取る方針だと，たとえば64bit整数だと最大64個しかオプションが定義できません．
65個目のオプションが必要なった場合は API/ABI を追加，または変更しなければなりません．そのため細かい制御には不向きであると言えます
一方文字列で指定する方針だと，API/ABIを保ったまま柔軟な拡張ができます．
たとえば
tame("get*", NULL);
tame("getpw[uid==1000]", NULL);
などです．
この手の拡張は，定数でOR作戦だと実質無理です．
個人的には，３番目の理由だけで，私は定数をORで指定する方式は選択肢にさえなりません
Re:pledge (スコア:2)
ですねぇ。加えて言うと、文字列なら他の言語との親和性も高くなりますしね。ヘッダファイル等での余計な定義も不要になりますし。
ほえほえ
Re: (スコア:0)
それでも文字列はないな。考慮しなきゃならないケースが無駄に多くなりすぎる。
それはバグの温床だし、すなわちセキュリティホールの温床にもなりうる。
それに理由3は割と簡単にあとから拡張可能だしね。
Re: (スコア:0)
文字列の方が拡張性が高いのはわかるんですが、保守性も高いんでしょうか？
プリコンパイルやリンクでチェックやリンクできずにエラーになるならいいと思うんですけど、
実行時にしかエラーがわからなさそうなものってどうにも抵抗が…
（javaや.NETのリフレクションで文字列指定するのとかも抵抗があるんですよね。あっちはIDEのリファクタリング機能の対象外になるのも敬遠したくなる所以ですが）。
優秀なIDEがあればコードtypoなんかは警告だしてくれそうですが、それもあるかどうか不明ですし。
実際に作る時はマクロでもつかってそのあたりの不安を埋めてくんでしょうかね？
# 最近jsばかり書いてるせいか、どうせ文字列つかうなら文字列テーブルにすればいいのにとも。