アカウント名:
パスワード:
ユーザー名を指定する個所で数字で始まるユーザー名を指定すると、そのユーザーの代わりに「root」が指定されたことになってしまう
な? 障害者レベルの設計だろ?
おまけにsystemdの開発者がクソなのは、PulseAudioやAvahiの時点で既に分かっていたので、今回の「数字で始まるユーザー名が不正なのであってsystemdのバグではない」という返答が帰ってくるまでが想定の範囲内という酷さ。こいつらは、PID 1で常時動作するようなサービスマネージャーを、そこらの3分間クイックハックレベルの思考で設計してる。
かつての 1ツイート(140字以内)でsystemdをクラッシュさせる方法 [gihyo.jp]や
(古典的)c言語の思想が根幹に染み付いたプログラマ(のコミュニティ)なら当然の考え方でしょ引数の正当性は渡す側が責任を持つもので渡された側でチェックして対処するなんて非効率
ご冗談を。どこでそんな偏見を覚えましたか?C言語の API で入力チェックしてなかったら、即バグ扱いだよ.普通。
仕様書読んだら嫌でも覚えるんじゃないですかね。 fopen() のアクセスモード引数に既定のもの以外の文字列を渡した場合の動作は未定義です、 free() に alloc 系の関数が返したのではないポインタを渡した場合の動作は未定義です、 strcpy() にオーバーラップする文字列を渡した場合の動作は未定義です、 etc etc...
「未定義」は言語やライブラリの仕様としての話であり、OS、あるいはそれに類するレイヤーの実装としては、できる限りの安全策、つまり、引数のチェックを行うべきであるってことですよね。
> パフォーマンスに影響するため、チェックをしない(最小限にしている)システムはいくらでもある。
というより、そういう実装を許すために他の言語ではチェックを義務付けているようなものも言語仕様で未定義にしている。ゼロオーバーヘッドの代償。
fclose(NULL); とか知らない?
うーん。ポインタ・デリファレンスの問題と引数のはなしを混同している時点でまともに C言語でプログラムしたことがないのがわかってしまうのだが...
このあたりの誤解されやすさが、C言語の欠陥なんだろうな。
fclose は引数の NULL チェックをしていないぞ、という指摘なんだがどこにポインタ・デリファレンスが絡んでくるの?
いや、もうこれ、「知りたかったら勉強してねとしか」としか答えようがないな。
開いていないファイルを閉じる意味はないのでNULLチェックも不要だろう…ついでにいうとファイルを開いて閉じるだけのソフトは実用上意味がないのでfcloseにNULLを参照しているポインタを渡すようなプログラムは多分他にもバグがある。
>開いていないファイルを閉じる意味はないのでNULLチェックも不要だろう…『C言語の API で入力チェックしてなかったら、即バグ扱いだよ.普通。』って言ったのは (#3240550) だからね。
fcloseは普通のAPIではなく特殊なAPIなので問題ない。ではだめですか?正直これに関しては下手にチェックするよりエラー吐かせるほうがデバッグが楽。くどいようだが実用上この関数にNULLを渡すようなプログラムは危ない。
>そこで不正ポインタのチェックをしていないだけ(そもそもCではできない)その理屈だと free には NULL を渡しても問題ないこととの整合性が取れない。
分かりやすい例として fclose を挙げたけど、それだけじゃないのは#3240584 [srad.jp]が示してるとおりなんだよなぁ…他にも fs0x7f 氏が昔日記で挙げた事例 [srad.jp]なんかもある。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
systemdはそもそもの設計からして欠陥品 (スコア:4, すばらしい洞察)
ユーザー名を指定する個所で数字で始まるユーザー名を指定すると、そのユーザーの代わりに「root」が指定されたことになってしまう
な? 障害者レベルの設計だろ?
おまけにsystemdの開発者がクソなのは、PulseAudioやAvahiの時点で既に分かっていたので、今回の「数字で始まるユーザー名が不正なのであってsystemdのバグではない」という返答が帰ってくるまでが想定の範囲内という酷さ。
こいつらは、PID 1で常時動作するようなサービスマネージャーを、そこらの3分間クイックハックレベルの思考で設計してる。
かつての 1ツイート(140字以内)でsystemdをクラッシュさせる方法 [gihyo.jp]や
Re: (スコア:0)
(古典的)c言語の思想が根幹に染み付いたプログラマ(のコミュニティ)なら当然の考え方でしょ
引数の正当性は渡す側が責任を持つもので渡された側でチェックして対処するなんて非効率
Re:systemdはそもそもの設計からして欠陥品 (スコア:0)
ご冗談を。どこでそんな偏見を覚えましたか?
C言語の API で入力チェックしてなかったら、即バグ扱いだよ.普通。
Re:systemdはそもそもの設計からして欠陥品 (スコア:1)
仕様書読んだら嫌でも覚えるんじゃないですかね。 fopen() のアクセスモード引数に既定のもの以外の文字列を渡した場合の動作は未定義です、 free() に alloc 系の関数が返したのではないポインタを渡した場合の動作は未定義です、 strcpy() にオーバーラップする文字列を渡した場合の動作は未定義です、 etc etc...
Re: (スコア:0)
「未定義」は言語やライブラリの仕様としての話であり、
OS、あるいはそれに類するレイヤーの実装としては、できる限りの安全策、つまり、引数のチェックを行うべきであるってことですよね。
Re: (スコア:0)
Re: (スコア:0)
> パフォーマンスに影響するため、チェックをしない(最小限にしている)システムはいくらでもある。
というより、そういう実装を許すために他の言語ではチェックを義務付けているようなものも言語仕様で未定義にしている。ゼロオーバーヘッドの代償。
Re: (スコア:0)
fclose(NULL); とか知らない?
Re: (スコア:0)
うーん。ポインタ・デリファレンスの問題と引数のはなしを混同している時点でまともに C言語でプログラムしたことがないのがわかってしまうのだが...
このあたりの誤解されやすさが、C言語の欠陥なんだろうな。
Re: (スコア:0)
fclose は引数の NULL チェックをしていないぞ、という指摘なんだがどこにポインタ・デリファレンスが絡んでくるの?
Re: (スコア:0)
いや、もうこれ、「知りたかったら勉強してねとしか」としか答えようがないな。
Re: (スコア:0)
開いていないファイルを閉じる意味はないのでNULLチェックも不要だろう…
ついでにいうとファイルを開いて閉じるだけのソフトは実用上意味がないのでfcloseにNULLを参照しているポインタを渡すようなプログラムは多分他にもバグがある。
Re: (スコア:0)
manにあるようにEBADF返すケースはあるわけでしょ
そこで不正ポインタのチェックをしていないだけ(そもそもCではできない)
Re: (スコア:0)
Re: (スコア:0)
>開いていないファイルを閉じる意味はないのでNULLチェックも不要だろう…
『C言語の API で入力チェックしてなかったら、即バグ扱いだよ.普通。』って言ったのは (#3240550) だからね。
Re: (スコア:0)
fcloseは普通のAPIではなく特殊なAPIなので問題ない。
ではだめですか?正直これに関しては下手にチェックするよりエラー吐かせるほうがデバッグが楽。
くどいようだが実用上この関数にNULLを渡すようなプログラムは危ない。
Re: (スコア:0)
>そこで不正ポインタのチェックをしていないだけ(そもそもCではできない)
その理屈だと free には NULL を渡しても問題ないこととの整合性が取れない。
Re: (スコア:0)
分かりやすい例として fclose を挙げたけど、それだけじゃないのは#3240584 [srad.jp]が示してるとおりなんだよなぁ…
他にも fs0x7f 氏が昔日記で挙げた事例 [srad.jp]なんかもある。
Re: (スコア:0)