アカウント名:
パスワード:
Cではバッファーエラー(CWE-119)・領域外読み込み(CWE-125)・NULLポインター参照(CWE-476)の順になっている。
他の言語ではそもそも脆弱性になりえないから…と思ったが、ここではC++も「他の言語」なのか。みんな意外とC++の機能をちゃんと使っているということか
ダメなプログラムを書いた責任を言語に擦り付けるようじゃ何使ってもダメでしょチンパンジーがキーボードを乱打しても正常なプログラムが書けるような言語があるなら話は別だけど
人間の注意力に責任を押し付けるようなやつは何をやってもダメ
例えばポインタの存在しないプログラムで同じように初期化や値チェックが雑なプログラムを組んだらNULLポで落ちない代わりによくわからない想定外の動作をするプログラムになるだけでしょ?バッファーオーバランでセキュリティリスクになるよりはランタイムエラーで落ちる方が良いとか?注意力に限界はあるしプログラムにバグが発生するのはあたりまえそれをテストデバッグせずに言語が悪いと言う人はプログラマーに向いてない※注意力散漫でもバグが無いプログラムを作れる言語なりシステムがあるなら教えてほしい
ソースを読まずにお前が悪いと言う人はスラドに向いてない。Pythonは人気が高いにも関わらず脆弱性の割合が低いってことが書いてあるぞ。
Pythonでポインタとか使えたっけ?
低レベルな操作ができない(あるいはできることが少ない)言語は、それに起因した脆弱性は減るよ。それは特性の問題で、言語の良し悪し(や、ユーザーの良し悪し)とは、直接関係ははない。
かといって低レベルな操作が仕様にない言語だけになると、その辺やるのにいきなり機械語書くのか?みたいな問題になるから、たとえ脆弱性を作りこみやすいとしても、低レベル操作が可能な言語は必要だ。
# 包丁とミキサーなら包丁のほうが負傷事故は起きやすいが、じゃあ包丁がいらないかと言えばそんなことはない
言語特性起因の脆弱性が(言語内でも言語外でも)トップにきてる時点で、セイフティが存在しないか役に立ってない残念言語ってことにならない?
# ミキサーの負傷事故が少ないのは、指をミキサーに突っ込んだ状態で# 動かないようにするとか、絶縁して漏電しないように安全性が考慮されているから
で、ミキサーで野菜の皮を剥いたり、生魚の鱗を取ったり、エビの背腸をとったり、食肉をダイスカットできるわけ?
機能を制限すればリミッターや安全装置はつけられるけど、その分、汎用性は失われる。その汎用性が必要なときに、仕方なくリミッターや安全装置がない道具を使わざるを得ないこともある。そこにリミッターも安全装置もないのは欠陥ではないよ。汎用性を維持するために付けられなかっただけ。
LinuxというカーネルはgccのC言語拡張を使ってて、OpenMandrivaの人たちなんかがパッチを当ててclangでビルドできるようにしていると聞いているけど、C言語は野菜の皮を剥けるのか剥けないのかどっち側なんでしょ?
データベース関係だと、コンパイル結果がCのソースになるプログラム言語というかコンバータというかがありますけど、素のCの作法にしなかったのは生魚の鱗が取りづらいんからじゃないかなあ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
ともあれC言語は滅びるべきである (スコア:0)
他の言語ではそもそも脆弱性になりえないから…と思ったが、ここではC++も「他の言語」なのか。みんな意外とC++の機能をちゃんと使っているということか
Re: (スコア:0)
ダメなプログラムを書いた責任を言語に擦り付けるようじゃ何使ってもダメでしょ
チンパンジーがキーボードを乱打しても正常なプログラムが書けるような言語があるなら話は別だけど
Re: (スコア:1)
人間の注意力に責任を押し付けるようなやつは何をやってもダメ
Re: (スコア:0)
例えばポインタの存在しないプログラムで同じように初期化や値チェックが雑なプログラムを組んだらNULLポで落ちない代わりによくわからない想定外の動作をするプログラムになるだけでしょ?
バッファーオーバランでセキュリティリスクになるよりはランタイムエラーで落ちる方が良いとか?
注意力に限界はあるしプログラムにバグが発生するのはあたりまえ
それをテストデバッグせずに言語が悪いと言う人はプログラマーに向いてない
※注意力散漫でもバグが無いプログラムを作れる言語なりシステムがあるなら教えてほしい
Re: (スコア:0)
ソースを読まずにお前が悪いと言う人はスラドに向いてない。
Pythonは人気が高いにも関わらず脆弱性の割合が低いってことが書いてあるぞ。
Re: (スコア:0)
ソースを読まずにお前が悪いと言う人はスラドに向いてない。
Pythonは人気が高いにも関わらず脆弱性の割合が低いってことが書いてあるぞ。
Pythonでポインタとか使えたっけ?
低レベルな操作ができない(あるいはできることが少ない)言語は、それに起因した脆弱性は減るよ。
それは特性の問題で、言語の良し悪し(や、ユーザーの良し悪し)とは、直接関係ははない。
かといって低レベルな操作が仕様にない言語だけになると、その辺やるのにいきなり機械語書くのか?みたいな問題になるから、たとえ脆弱性を作りこみやすいとしても、低レベル操作が可能な言語は必要だ。
# 包丁とミキサーなら包丁のほうが負傷事故は起きやすいが、じゃあ包丁がいらないかと言えばそんなことはない
Re:ともあれC言語は滅びるべきである (スコア:0)
言語特性起因の脆弱性が(言語内でも言語外でも)トップにきてる時点で、
セイフティが存在しないか役に立ってない残念言語ってことにならない?
# ミキサーの負傷事故が少ないのは、指をミキサーに突っ込んだ状態で
# 動かないようにするとか、絶縁して漏電しないように安全性が考慮されているから
Re: (スコア:0)
で、ミキサーで野菜の皮を剥いたり、生魚の鱗を取ったり、エビの背腸をとったり、食肉をダイスカットできるわけ?
機能を制限すればリミッターや安全装置はつけられるけど、その分、汎用性は失われる。
その汎用性が必要なときに、仕方なくリミッターや安全装置がない道具を使わざるを得ないこともある。
そこにリミッターも安全装置もないのは欠陥ではないよ。汎用性を維持するために付けられなかっただけ。
Re: (スコア:0)
LinuxというカーネルはgccのC言語拡張を使ってて、OpenMandrivaの人たちなんかがパッチを当ててclangでビルドできるように
していると聞いているけど、C言語は野菜の皮を剥けるのか剥けないのかどっち側なんでしょ?
データベース関係だと、コンパイル結果がCのソースになるプログラム言語というかコンバータというかがありますけど、
素のCの作法にしなかったのは生魚の鱗が取りづらいんからじゃないかなあ。