アカウント名:
パスワード:
Cではバッファーエラー(CWE-119)・領域外読み込み(CWE-125)・NULLポインター参照(CWE-476)の順になっている。
他の言語ではそもそも脆弱性になりえないから…と思ったが、ここではC++も「他の言語」なのか。みんな意外とC++の機能をちゃんと使っているということか
ダメなプログラムを書いた責任を言語に擦り付けるようじゃ何使ってもダメでしょチンパンジーがキーボードを乱打しても正常なプログラムが書けるような言語があるなら話は別だけど
人間の注意力に責任を押し付けるようなやつは何をやってもダメ
ただ、この手の指摘って実害はないけれどコーディング上はだめというものも含まれているからただ統計結果だけだとゴミの評価にしかならないというのが個人的な感想。企業がやってるコーディングのセキュリティチェックなんかがよい例なんじゃないだろうか。ツールの出力結果を成形して貼り付けるだけで中身なんて何も見てないからなあれ。ほんと存在価値がない。まぁ。全部が全部そういう実害のない脆弱性というわけでもないだろうけれど。。。
基本的なことをちゃんと手抜かずにすればいいのにCの場合、めんどくさがってやらないやつが多いという話でもあるんだと思う。手間を惜しまず、手続きさえちゃんとふめば、Cが一番安定した言語だと今でも思うよ。基幹部分を作るのならばの話。
あのさぁ……データの収集元になったNVDや脆弱性データベースって見たことない?そこに「実害はないけれどコーディング上はだめ」というものが含まれていると思う?
例えばポインタの存在しないプログラムで同じように初期化や値チェックが雑なプログラムを組んだらNULLポで落ちない代わりによくわからない想定外の動作をするプログラムになるだけでしょ?バッファーオーバランでセキュリティリスクになるよりはランタイムエラーで落ちる方が良いとか?注意力に限界はあるしプログラムにバグが発生するのはあたりまえそれをテストデバッグせずに言語が悪いと言う人はプログラマーに向いてない※注意力散漫でもバグが無いプログラムを作れる言語なりシステムがあるなら教えてほしい
Cでも初期化や値チェックがだめでよいわけじゃないので、なんの比較にもなっていない。
バグが完全に無くならないかぎり、少なくしようとするのに意味はないという意見には賛成できない。
例えばポインタの存在しないプログラムで同じように初期化や値チェックが雑なプログラムを組んだらNULLポで落ちない代わりによくわからない想定外の動作をするプログラムになるだけでしょ?バッファーオーバランでセキュリティリスクになるよりはランタイムエラーで落ちる方が良いとか?
例えば流行りのRustなら、ランタイムエラーどころか、そもそもビルドを通さない仕組みがいくつかあるよな。レースコンディションとかはきっちり叱ってくれる。解放済みのポインタの使用も。何もないよりは、こっちの方が断然良い。
注意力に限界はあるしプログラムにバグが発生するのはあたりまえ
そう。それを言語がカバーして叱ってくれるんだぜ。やっぱり言語の選択は重要よ。
言語側でカバーして、文法レベルでエラーにしてくれるのが良いのはもちろんだが、Cは最近の静的解析使えばかなり改善する。いまどきの静的解析はとても優秀で一昔前だとリソース的に無理だったような、そこまでの実行パスで取りうる値を網羅的にチェックしてくれたりするんだよな。解放済みのポインタ参照なんか当たり前のように検出してくれる。valgrindはもう無くていいレベル
組み込み業界は秀丸やサクラエディタ使ってりゃマシな方でひどいとメモ帳ですよ。解析ツールなんて予算が降りません。
よし、ベターなCを作って名前に+でも加えよう
おまえのではまだ不足だから、俺がさらに改善して名前にもう一個+を加えとくわ。
ソースを読まずにお前が悪いと言う人はスラドに向いてない。Pythonは人気が高いにも関わらず脆弱性の割合が低いってことが書いてあるぞ。
Pythonでポインタとか使えたっけ?
低レベルな操作ができない(あるいはできることが少ない)言語は、それに起因した脆弱性は減るよ。それは特性の問題で、言語の良し悪し(や、ユーザーの良し悪し)とは、直接関係ははない。
かといって低レベルな操作が仕様にない言語だけになると、その辺やるのにいきなり機械語書くのか?みたいな問題になるから、たとえ脆弱性を作りこみやすいとしても、低レベル操作が可能な言語は必要だ。
# 包丁とミキサーなら包丁のほうが負傷事故は起きやすいが、じゃあ包丁がいらないかと言えばそんなことはない
言語特性起因の脆弱性が(言語内でも言語外でも)トップにきてる時点で、セイフティが存在しないか役に立ってない残念言語ってことにならない?
# ミキサーの負傷事故が少ないのは、指をミキサーに突っ込んだ状態で# 動かないようにするとか、絶縁して漏電しないように安全性が考慮されているから
で、ミキサーで野菜の皮を剥いたり、生魚の鱗を取ったり、エビの背腸をとったり、食肉をダイスカットできるわけ?
機能を制限すればリミッターや安全装置はつけられるけど、その分、汎用性は失われる。その汎用性が必要なときに、仕方なくリミッターや安全装置がない道具を使わざるを得ないこともある。そこにリミッターも安全装置もないのは欠陥ではないよ。汎用性を維持するために付けられなかっただけ。
LinuxというカーネルはgccのC言語拡張を使ってて、OpenMandrivaの人たちなんかがパッチを当ててclangでビルドできるようにしていると聞いているけど、C言語は野菜の皮を剥けるのか剥けないのかどっち側なんでしょ?
データベース関係だと、コンパイル結果がCのソースになるプログラム言語というかコンバータというかがありますけど、素のCの作法にしなかったのは生魚の鱗が取りづらいんからじゃないかなあ。
無限の猿に無限時間書かせればばいずれ意味解析通るので正常がなにか定義しないとダメ。
正常をどう定義したところで無限の数の猿に無限の時間タイプさせれば意味解析も構文チェッカも通るでしょ。
一体いつから正常なプログラムが有限と錯覚していた?
元コメは無限が2つあるので、正常なプログラムが無限でも別に発散したりしないのでは
無限の猿は日常的な感覚で言えば可算無限集合にしかならないでしょ?
# どんな日常だ
正常なプログラムを全部猿がかけるって話ではないでしょ
無限の話なので「全部」という概念が適切かはわからないけど、「任意」の正常の定義について猿がプログラムを書けるという主張でしょ?空やコメントだけのプログラムは大抵有効なプログラムなので、特定の正常なプログラムを有限の猿が書けることは自明でしょう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
ともあれC言語は滅びるべきである (スコア:0)
他の言語ではそもそも脆弱性になりえないから…と思ったが、ここではC++も「他の言語」なのか。みんな意外とC++の機能をちゃんと使っているということか
Re:ともあれC言語は滅びるべきである (スコア:0)
ダメなプログラムを書いた責任を言語に擦り付けるようじゃ何使ってもダメでしょ
チンパンジーがキーボードを乱打しても正常なプログラムが書けるような言語があるなら話は別だけど
Re:ともあれC言語は滅びるべきである (スコア:1)
人間の注意力に責任を押し付けるようなやつは何をやってもダメ
Re: (スコア:0)
ただ、この手の指摘って実害はないけれどコーディング上はだめというものも含まれているから
ただ統計結果だけだとゴミの評価にしかならないというのが個人的な感想。
企業がやってるコーディングのセキュリティチェックなんかがよい例なんじゃないだろうか。
ツールの出力結果を成形して貼り付けるだけで中身なんて何も見てないからなあれ。ほんと存在価値がない。
まぁ。全部が全部そういう実害のない脆弱性というわけでもないだろうけれど。。。
基本的なことをちゃんと手抜かずにすればいいのに
Cの場合、めんどくさがってやらないやつが多いという話でもあるんだと思う。
手間を惜しまず、手続きさえちゃんとふめば、Cが一番安定した言語だと今でも思うよ。
基幹部分を作るのならばの話。
Re: (スコア:0)
あのさぁ……データの収集元になったNVDや脆弱性データベースって見たことない?
そこに「実害はないけれどコーディング上はだめ」というものが含まれていると思う?
Re: (スコア:0)
例えばポインタの存在しないプログラムで同じように初期化や値チェックが雑なプログラムを組んだらNULLポで落ちない代わりによくわからない想定外の動作をするプログラムになるだけでしょ?
バッファーオーバランでセキュリティリスクになるよりはランタイムエラーで落ちる方が良いとか?
注意力に限界はあるしプログラムにバグが発生するのはあたりまえ
それをテストデバッグせずに言語が悪いと言う人はプログラマーに向いてない
※注意力散漫でもバグが無いプログラムを作れる言語なりシステムがあるなら教えてほしい
Re: (スコア:0)
Cでも初期化や値チェックがだめでよいわけじゃないので、なんの比較にもなっていない。
バグが完全に無くならないかぎり、少なくしようとするのに意味はないという意見には
賛成できない。
Re: (スコア:0)
例えば流行りのRustなら、ランタイムエラーどころか、そもそもビルドを通さない仕組みがいくつかあるよな。
レースコンディションとかはきっちり叱ってくれる。解放済みのポインタの使用も。
何もないよりは、こっちの方が断然良い。
そう。
それを言語がカバーして叱ってくれるんだぜ。やっぱり言語の選択は重要よ。
Re: (スコア:0)
言語側でカバーして、文法レベルでエラーにしてくれるのが良いのはもちろんだが、Cは最近の静的解析使えばかなり改善する。
いまどきの静的解析はとても優秀で一昔前だとリソース的に無理だったような、そこまでの実行パスで取りうる値を網羅的にチェックしてくれたりするんだよな。解放済みのポインタ参照なんか当たり前のように検出してくれる。
valgrindはもう無くていいレベル
Re: (スコア:0)
組み込み業界は秀丸やサクラエディタ使ってりゃマシな方でひどいとメモ帳ですよ。
解析ツールなんて予算が降りません。
Re: (スコア:0)
よし、ベターなCを作って名前に+でも加えよう
Re: (スコア:0)
おまえのではまだ不足だから、俺がさらに改善して名前にもう一個+を加えとくわ。
Re:ともあれC言語は滅びるべきである (スコア:1)
Re: (スコア:0)
ソースを読まずにお前が悪いと言う人はスラドに向いてない。
Pythonは人気が高いにも関わらず脆弱性の割合が低いってことが書いてあるぞ。
Re: (スコア:0)
ソースを読まずにお前が悪いと言う人はスラドに向いてない。
Pythonは人気が高いにも関わらず脆弱性の割合が低いってことが書いてあるぞ。
Pythonでポインタとか使えたっけ?
低レベルな操作ができない(あるいはできることが少ない)言語は、それに起因した脆弱性は減るよ。
それは特性の問題で、言語の良し悪し(や、ユーザーの良し悪し)とは、直接関係ははない。
かといって低レベルな操作が仕様にない言語だけになると、その辺やるのにいきなり機械語書くのか?みたいな問題になるから、たとえ脆弱性を作りこみやすいとしても、低レベル操作が可能な言語は必要だ。
# 包丁とミキサーなら包丁のほうが負傷事故は起きやすいが、じゃあ包丁がいらないかと言えばそんなことはない
Re: (スコア:0)
言語特性起因の脆弱性が(言語内でも言語外でも)トップにきてる時点で、
セイフティが存在しないか役に立ってない残念言語ってことにならない?
# ミキサーの負傷事故が少ないのは、指をミキサーに突っ込んだ状態で
# 動かないようにするとか、絶縁して漏電しないように安全性が考慮されているから
Re: (スコア:0)
で、ミキサーで野菜の皮を剥いたり、生魚の鱗を取ったり、エビの背腸をとったり、食肉をダイスカットできるわけ?
機能を制限すればリミッターや安全装置はつけられるけど、その分、汎用性は失われる。
その汎用性が必要なときに、仕方なくリミッターや安全装置がない道具を使わざるを得ないこともある。
そこにリミッターも安全装置もないのは欠陥ではないよ。汎用性を維持するために付けられなかっただけ。
Re: (スコア:0)
LinuxというカーネルはgccのC言語拡張を使ってて、OpenMandrivaの人たちなんかがパッチを当ててclangでビルドできるように
していると聞いているけど、C言語は野菜の皮を剥けるのか剥けないのかどっち側なんでしょ?
データベース関係だと、コンパイル結果がCのソースになるプログラム言語というかコンバータというかがありますけど、
素のCの作法にしなかったのは生魚の鱗が取りづらいんからじゃないかなあ。
Re: (スコア:0)
無限の猿に無限時間書かせればばいずれ意味解析通るので正常がなにか定義しないとダメ。
Re: (スコア:0)
正常をどう定義したところで無限の数の猿に無限の時間タイプさせれば意味解析も構文チェッカも通るでしょ。
Re: (スコア:0)
一体いつから正常なプログラムが有限と錯覚していた?
Re: (スコア:0)
元コメは無限が2つあるので、正常なプログラムが無限でも別に発散したりしないのでは
Re: (スコア:0)
無限の猿は日常的な感覚で言えば可算無限集合にしかならないでしょ?
# どんな日常だ
Re: (スコア:0)
正常なプログラムを全部猿がかけるって話ではないでしょ
Re: (スコア:0)
無限の話なので「全部」という概念が適切かはわからないけど、「任意」の正常の定義について猿がプログラムを書けるという主張でしょ?
空やコメントだけのプログラムは大抵有効なプログラムなので、特定の正常なプログラムを有限の猿が書けることは自明でしょう。