【IT】C/C++に死を [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
プログラミング言語Cはおぞましい。いや、素晴らしくもある、もちろん。私たちの住む世界の大部分はCの上に作られている。そしてほとんどのコンピュータープログラミングの基礎をなしている、歴史的にも、実質的にも。Xavier Nielの革新的な “42” スクールのカリキュラムが、学生に標準Cライブラリー関数を一から書き直させることから始まるのはそれが理由だ。しかしCは、C自身が作り上げたこの世界にとってもはやふさわしくない。
「おぞましい」と言ったのは「悪い」ということではなく「畏敬の念を起こさせる怖さ」という意味だ。Cはモンスターになってしまった。あまりに多くの大砲を与えたためにユーザーは自分の足を撃ち抜いてしまう。豊富な体験が教えるところによると、セキュリティーホールにむしばまれることなく大量のCコードを書くことは非常に困難であり「事実上不可能」になりつつある。2年前、私は最初の「Cに死を［Death To C］」の記事にこう書いた：
原理上、ソフトウェアが成長し進化して成熟度を増すほど、セキュリティー脆弱性は複雑になっていく。しかし、C/C++で書かれたソフトウェアにそれは当てはまらない。バッファーオーバーフローや宙ぶらりんのポインターのために壊滅的セキュリティーホールが生まれる事態は、繰り返し繰り返し起こっていて、昔も今も変わることがない。
私たちはこれ以上巨大な口を開けたセキュリティーの盲点を放っておくことはできない。引退して別の言語に取って代わられる時期はとうに過ぎている。問題なのは、ほとんどの近代言語はCを置き換えようという意欲すら持っていないことだ。〈中略〉どの言語もCが最も得意とすることに長けていない ―― 例えばシステムの奥深くまで掘り下げてマッハスピードで動くこと。
あなたがデベロッパーなら、私の言いたいことはもちろんわかっているだろう。Rustの長所を並べることだ。実際これは有望なC/C++の後継だ。2年前に私は、新規の下層レベルコーディングをCではなくRustで書くことを勧めた。つまるところ、穴に関して何よりも大切なのは、掘るのをやめることだ。
Security tips when programming in C (2017 edition):
1) Stop typing
2) Delete what you've already typed
［Cでプログラミングする際のセキュリティー心得（2017年版）：
1）タイプするのをやめる
2）すでにタイプしたものを削除する］
今私は、エンジニアが既存のCコードをリファクタリングするとき、特にパーサーなどの入力ハンドラーを書き直すとき ―― ゆっくりと、すこしずつ ―― Rustで置き換えるように真剣に勧めている。
http://jp.techcrunch.com/2017/07/17/20170716death-to-c/ >>279
もとの記事読めよ
どこに問題あるのか、どう言う対処が可能なのか書いてあるから
俺は余りC++知らないのでCの話するけど、Cである程度のプログラム組んだことがあればstrcpy()とかscsnf()の問題とかみんな知っているだろ
だからまずインターフェースを同じにしたままライブラリを書き直して行けって言っているんだよ >>247
インラインアセンブラ弄くってる時に何となく覚えた感じだな
表面的な知識としては、わかってるつもりだったけど >>282
引数の受け渡しと自動変数の確保に使われるスタックフレーム
メモリ確保に使われるメモリヒープ領域
初期値ありのDATA領域
初期値なしのBSS領域
あたりを知っているとよいかも。まあＣのプログラムに直接関係しないけど。
組み込みなら上記は必須でさらに
ROMに配置されるデータ、起動時にRAMにコピーされるデータ
を意識ししないと、少ないRAMを食いつぶすし、
パソコンではあまり使わない、volatileで最適化抑止をきちんと行わないと
ペリフェラルレジスタへの書き込みが最適化で消えるし、、、
などなど独特の注意点も多いよね。 LISPなんて意識高い系だろ
かっこつけすぎ なんちて >>280
> >>96
> 俺は、若い頃にハードウェアの設計から初めてOSからアプリケーションまで全部LISPで作ったマシンを実際に作り上げて
> LISPで実質的になんでもできる
すげー
> 事を証明した先生に教わったけどなあ
> haskelとかでも何でもできるよ
がっかり >>267
そもそもRustはC/C++がごりごりに書けて、C/C++に不満があるプログラマ向けの言語。
C/C++を経ずにRustやっても大変なだけだと思う。 C/C++を叩いているやつ、知ってるか？
Ruby.exeも Perl.exeも Python.exeも C言語で作られていると言う事実を
Jaba.exeと php.exeは知らんが、C/C++で作られているはず
一方で C/C++は C/C++で作られている >>263
#include<stdio.h>
#include <sanitizer/asan_interface.h>
static char a[200],poison[10],b[200];
int main(void) {
printf("Hello C world\n");
ASAN_POISON_MEMORY_REGION(poison, 10);
int i;
for(i=0;i<200;i++) { a[i]='A'; }
for(i=0;i<200;i++) { b[i]='0'; }
for(i=190;i<220;i++) { printf("%c",a[i]); }
printf("\n");
return 0;
}
こういうのは、全員使うべき。
これ、どうやって実現してるの？
素直に考えると、遅そうなんだけども。 >>275
そのあたりでいくらぐらいなんだろうね。
16bitでも100円で使えるから、それよりグンと安いってこと？ >>291
CLANGの動的解析のASANは、メモリ保護機能を使っていると思ったけど。
だから、使える環境に制限があるのですよ。
CLANGの静的解析機能も強力なのですよ。未初期化変数などはもちろんのこと
メモリリーク（mallocしたけど、それを開放するパスがない）や
戻り値が不定になるパスも検出できるし。 >>292
未だにＰＩＣがあるよ。
ばら売りでも５０円くらいから。 >>274
リアルタイムの世界でC#はありえない
くっそ遅い AI時代に「何もしない」取り残される日本の危機
業務のデジタル化が進まぬ日本は34カ国中最下位に
http://jbpress.ismedia.jp/articles/-/50416 気の効いたコンパイラか、ソース解析して穴が無いかチェックするツールが開発されてきてないの？ C/C++が死ぬ前に日本が死にそうなんだが
潰れる会社に必ずいる｢静かな殺し屋｣の正体
忖度できる便利な人材は危ない
http://toyokeizai.net/articles/-/179756 Cの一番の問題は、文字列
・基本型でない
・NULターミネート式で、バイナリを扱えない
・長さ情報、粒度情報を持たず、操作のオーバヘッドが大きい
・同時に、アドレスチェックが難しい
だめだよ、これじゃ >>247
&でアドレスを返して、呼び出し元でポインタアクセスしてみると、
スタックにあったローカル変数が消えていてmemory acccess violationになるという話でないんか?
引数も返り値も値渡しで問題が起きない気が… >>299
あれより実装が簡単な、文字列の表現法を教えて欲しい。 >>300
すぐ間違いに気が付いて
>>251 とかで謝っているのに、、のに、、、のに、、、。
御免よ。指摘はごもっともさ。
>>291
ttps://solid.kmckk.com/SOLID/archives/703
これを参考にしてみてください。 >>293
なるほど。
#include<stdio.h>
#include <sanitizer/asan_interface.h>
static char a[10],poison[10],b[10];
int main(void) {
printf("Hello C world\n");
ASAN_POISON_MEMORY_REGION(poison, 10);
int i;
for(i=0;i<10;i++) { a[i]='A'; }
for(i=0;i<10;i++) { b[i]='0'; }
printf("%llx\n",(unsigned long long int)a);
printf("%llx %ld\n",(unsigned long long int)poison,(unsigned long )poison - (unsigned long )a);
printf("%llx %ld\n",(unsigned long long int)b,(unsigned long)b-(unsigned long)poison);
for(i=10;i<19;i++) { printf("%c",a[i]); }
printf("\n");
return 0;
}
clang -g -fsanitize=address poison2.c -o poison2.o
Hello C world
138ce80
138ce40 -64
138cec0 128
=================================================================
==869==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00000138ce8a at pc 0x0000004ea57f bp 0x7ffc0df83e50 sp 0x7ffc0df83e48
READ of size 1 at 0x00000138ce8a thread T0
0x00000138ce8a is located 54 bytes to the left of global variable 'b' defined in 'poison2.c:4:30' (0x138cec0) of size 10
0x00000138ce8a is located 0 bytes to the right of global variable 'a' defined in 'poison2.c:4:13' (0x138ce80) of size 10
メモリ管理ユニットの粒度がバイト単位も可能なのか、最近のは？？？
配列a と配列b の間に毒沼設定したのに、aの64バイト前に設定されてるように見える。
a と b は１２８バイト離れている。-fno-omit-frame-pointerが強制されるのか。
どこでひっかけてるのかよくわからないが、速度が落ちないんだったら、すごい話。 >>299
ドライバでもなければ
生char使わんだろ。 >>299
ＤＪＢのソースを読むといい。
文字列が使えると言っても、charの配列だから、長さと内容を別に管理すればいい。
そして、ことあるごとに長さチェックをして、容量オーバーしてないかを見張る。
もしバグがあったら賞金出す、としていてバグが無かった。言いがかり的なのはあったけども。
http://cr.yp.to/qmail.html
標準ライブラリでおかしなものは作り直す。面倒だけども、そういう方法もある。 >>297
> 気の効いたコンパイラか、ソース解析して穴が無いかチェックするツールが開発されてきてないの？
根本的な問題として、プログラマーの意図がソースコードにどう反映されているのかわからないんじゃないのかな。
ポインターまわりで。
それの自由度を無くすとガベージコレクションやＶＭやＪＩＴになるのだろう。 ポインタはまじでうざいよな。
ハードの性能上がったんだからメモリ管理なんてハード側でやろうぜｗ >>299
気になるのなら、自前の文字列型を作ればいいだけ ■真相深入り！◆虎ノ門ニュース■
7/18(火) 百田尚樹・居島一平
https://www.youtube.com/watch?v=56YQaIKtPQY
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
毎週月〜金 朝８時から生放送！ LIVE放送終了後も動画で見れます♪
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
※ニコ生、フレッシュでも放送中 >>305
fopen
ですら生char要求するけど。 Cは息長いからな。
PASCALなども長いけどオープン系じゃ圧倒的な歴史。 >>290
大抵のLISPはLISPで書いてあるな
pypyというpythonのサブセットで書いたpythonの処理系もある
開発中だがCで書いたpythonより速い場合もあるとか
JAVAも今の処理系は結構実行が速いのでいくつかの言語処理系をJAVAで書いたり jabaは知らんけどJAVAコンパイラはJAVAで記述されているよ セキュリティーホールの温床になるからCは駄目という話なのにそこに触れず持ち上げてる奴はバカなの？ >>275
今時の家電製品などで使うような専用ICもピン数を減らすなどの理由で電源を入れるだけでもシーケンス動作が必須だったりするんだよ
電源ONの時にいくつかのICにシリアルのコマンドをいくつか投げるとか、ボタンを押した時にスイッチのON/OFFではなくてエンコードしたシリアルの
コマンドを送るような用途なら小物の部品感覚で使えるPICのような「シーケンサ」が適している 結局問題提起すら読まず理解しない者がCを使うからセキュリティーホールができてしまうのだろうな >>1
リンク先で言われているバッファオーバフローやポインタの問題は、
最近のC++ならほぼ解決しているけどな。正直生ポインタなんて最近使わないぞ。 DBのOracleがJavaに移行したのは衝撃だったな >>37
知ったかだなぁ
文化的な背景なんて関係ねーよ
以下３点が理由だ
・（組み込み環境で主流の）linuxやtronのデバイスドライバがCでしか書けないから
・（言語的に単純な）Cが一番早く開発環境揃うから
・Javaとかも動かせなくはないけど（スマホとかのリッチな環境でも無けりゃ）クソ遅い&重いから リッチコードが使えない組み込み機器なんかじゃC以外考えられないわ
Cなら1MHzで動くコードもjavaが動く組み込みになると48Mhzとか当たり前のように要求されるからな バッファオーバーランなんて言語じゃなくOSの問題だろが >>83
初心者が使える程度の言語に存在価値あるのか？ >>331
難解な言語じゃないと存在価値ないとか意味不明 >>333
難解さ容易さが問題なのではない。
何ができて何ができないかだ。
初心者向け、あるいはその言語で解決しやすいように整えられた問題に対して、
出題者の意図に沿ったコードを書くのは、初心者向け言語には容易だ。
だけど、世の中にある仕様は、その人の都合を考えてくれるわけではない。 >>294
ということはメーカーが一括購入したらもっと安いのね。 >>330
OSやライブラリの問題
APIがバッファ長を必ず要求するようにしとけば、バッファオーバーフローは起きない >>338
Javaは配列の代入で必ず長さチェックがかかる仕様なんだよな
最初はバカにされていたけど、今となっては大正解 >>339
それを入れなきゃならんOS仕様の問題だわな。
シンビアンなんて、電力管理をプログラミングに求めてた訳で >>338
バッファを使うのはAPIだけじゃないんだけど。 >>338
そもそもそのOSやライブラリをを書くために使われる言語についての話題だと理解してる？ >>340
仮想化支援みたいな感じであんまオーバーヘッドがあるようならCPUとかハードでの支援機能があってもいいかもね
（バッファオーバーフロー対策のハード支援はあったと思うから、もしかしたら既にあるかもしれない）
もうC/C++とか超えた世界の話 javaは、androidとWebだけ。
C#は、windowsのアプリだけ。
c/c++は、すべての分野で使わエる。 >>292
NXPのLPC800とか、100円台で買える32bitマイコンもあるが、ボタン電池で
動かすとかだと、消費電力が大きくて使えない。 androidもスピードが要求される部分では、
jniでつないでc/c++で書かれている >>339
いくら代入で長さチェックしても、範囲チェックしないで、要素数を超える
配列要素にアクセスするバカはいるので無駄。 速度の為に余計なコートが混じってほしくないってだけのがC言語
セキュリティの問題もあるし、もう封印しちまえ。 死ぬべきなのは、C++言語ではなく、ついてこれないプログラマの方。 >>348
多分それもやってるよ。
JavaだとそこらへんExceptionになったと思うけど、それが長さチェックをやっているってこと javaはデストラクタがないから、ガベージコレクションが走るように、
明示的に的にnull設定しないといけない。 安 倍 晋 三 の 実 兄 、 安 倍 寛 信
三菱商事の核ミサイル担当重役は安倍晋三の実兄、安倍寛信
三菱重工の重役でもあるらしい
これがフクイチで核弾頭ミサイルを製造していた疑惑がある
書けばツイッターで速攻削除されている
私のツイートで、安倍政権に都合の悪い情報は速攻削除されている
これは驚いた ここまでやるのか
https://twitter.com/東海アマ/status/841451580339625984
3 9 歳 で 若 年 性 ア ル ツ ハ イ マ ー
2015年1月には、首相官邸で安倍首相と意見交換する機会を得て、
認知症になっても働くことができるということを伝えました。
でも、症状は着実に進んでいます。
https://twitter.com/onodekita/status/881710709624627200
世 界 教 師 マ 人 ト レ ー ヤ か ら 警 告
（まもなく、日本発の株式大暴落、次いで米国債大暴落の後、各国メディアに登場、ＵＦＯも）
認知症の過程は放射能汚染によって加速します。
若年性アルツハイマー病の原因となっており、
人々は肺炎やインフルエンザ、慢性疲労、癌、
ＨＩＶ/エイズなどに抵抗できなくなっています。
免疫システムの崩壊の結果がアレルギーです。
死者の数は、他のいかなる原因よりも多いです。
河川の汚染は犯罪と見られなければなりません。
問題は、日本政府が何も認めないことです。
多くの人々が放射能の影響で死んでいるのに、
彼ら（日本国民）は幻想の中に生きています。
日本の近海の食料は安全ではありません。
健康上のリスクは福島に近づくほど高まります。
福島の子供達は癌をもたらす被爆をしています。
福島の住人は廃炉後1、２年で戻れるでしょう。
マ人トレーヤは原発の閉鎖を助言されます。
マ人トレーヤによれば、飛行機など原子のパターンが妨害されると墜落します。
マ人トレーヤはいかなる人間よりも危険をよくご存じです。
マ人トレーヤの唇からますます厳しい警告と重みが発せられることを覚悟しなさい。
おれ、CASL２しかやったことないんだけど、CとかC++とかやるべきなのかな？ >>1
人間が会話に使う言語と違ってプログラム言語はコンピュータは最近の人工言語なのに、なんでこんなに種類があって複雑なの？ >>357
神様がプログラマーに罰を与えるために言語を分けたって聖書に書いてあるらしい >>55
サブマイコンとしてならいっぱいあるよ。
それこそソニーやパナでも使っている。 >>357
C/C++が出来れば、大抵のことはできるよ。 >>357
自然言語は勝手に言葉をつくっても
他に話す人がいないと意味ないから
まったく新しいものは生まれないけど
人工言語は人工だからこそ、いろいろ生まれるんだろうな
ここが気に入らない、ここはもっと改善できると思った人が
新しいものを生み出す javaのruntimeとかVM系は大抵c++
と言うかLLVMもgccもc++だから 言語なんて何でもいいよ、Application開発に最適であれば。 >>363
でもpythonで10行で済むコードが
1000行になったりするけどな
型と必要リソースが厳密なのは
利点でもあるが面倒臭くもある
boostとか持ち出すともはや別言語だし >>135
昔、IBMがJavaのWindows用のネイティブコンパイラ出して
Sunに怒られてたような記憶が・・・ Cを代替する言語は現実には無いからね。使わざるを得ない。
アセンブラはクリティカルな部分以外に使うのは非効率過ぎる。
煉瓦で超高層ビルを建てるぐらいアホくさい。
C++は半端に拡張してしまったのが問題だろうね。
Cみたいにコードが予測がつくほど低レイヤー言語ではないけど
抽象化が半端で記述の効率化がろくに図られてないという。 >>368
Excelsior JETはAOTコンパイラでネイティブコード吐けるけどOracleにJava互換認定を受けてらしいよ。
今はLLVMでもJava バイトコードをネイティブコードにできたんじゃないかな?
Excelsior JET
https://www.xlsoft.com/jp/products/jet/
> Excelsior JET は、JCK (Java Compatibility Kit test suite) をパスし、
> Oracle からライセンスされています。さまざまなプラットフォーム上において Java 互換認定を受けています。 >>367
それはないな。たとえPythonで書かれたライブラリに相当するC++ライブラリ
がなくても、Pythonで書けるコードはC++でも書ける。どうせ、行末文字の
セミコロンや、{}の省略くらいの節約なんぞ、生産性への影響はないに
等しい。
は、 >>278
ocamlはいいね。
もっとマルチコア対応してくれたらいいのに。 >>15
簡潔にして明瞭、まさに聖典
アレを読んで理解できない奴が他の初心者本読んでも、理解したつもりにされているだけで本質はなにも理解できてない 100年後もCは死んでないと断言できる
まぁ俺は間違いなく死んでる訳だが ■ このスレッドは過去ログ倉庫に格納されています
