【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/ >>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 は128バイト離れている。-fno-omit-frame-pointerが強制されるのか。
どこでひっかけてるのかよくわからないが、速度が落ちないんだったら、すごい話。 >>299
ドライバでもなければ
生char使わんだろ。 >>299
DJBのソースを読むといい。
文字列が使えると言っても、charの配列だから、長さと内容を別に管理すればいい。
そして、ことあるごとに長さチェックをして、容量オーバーしてないかを見張る。
もしバグがあったら賞金出す、としていてバグが無かった。言いがかり的なのはあったけども。
http://cr.yp.to/qmail.html
標準ライブラリでおかしなものは作り直す。面倒だけども、そういう方法もある。 >>297
> 気の効いたコンパイラか、ソース解析して穴が無いかチェックするツールが開発されてきてないの?
根本的な問題として、プログラマーの意図がソースコードにどう反映されているのかわからないんじゃないのかな。
ポインターまわりで。
それの自由度を無くすとガベージコレクションやVMやJITになるのだろう。 ポインタはまじでうざいよな。
ハードの性能上がったんだからメモリ管理なんてハード側でやろうぜw >>299
気になるのなら、自前の文字列型を作ればいいだけ ■真相深入り!◆虎ノ門ニュース■
7/18(火) 百田尚樹・居島一平
https://www.youtube.com/watch?v=56YQaIKtPQY
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
毎週月〜金 朝8時から生放送! 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
知ったかだなぁ
文化的な背景なんて関係ねーよ
以下3点が理由だ
・(組み込み環境で主流の)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
世 界 教 師 マ 人 ト レ ー ヤ か ら 警 告
(まもなく、日本発の株式大暴落、次いで米国債大暴落の後、各国メディアに登場、UFOも)
認知症の過程は放射能汚染によって加速します。
若年性アルツハイマー病の原因となっており、
人々は肺炎やインフルエンザ、慢性疲労、癌、
HIV/エイズなどに抵抗できなくなっています。
免疫システムの崩壊の結果がアレルギーです。
死者の数は、他のいかなる原因よりも多いです。
河川の汚染は犯罪と見られなければなりません。
問題は、日本政府が何も認めないことです。
多くの人々が放射能の影響で死んでいるのに、
彼ら(日本国民)は幻想の中に生きています。
日本の近海の食料は安全ではありません。
健康上のリスクは福島に近づくほど高まります。
福島の子供達は癌をもたらす被爆をしています。
福島の住人は廃炉後1、2年で戻れるでしょう。
マ人トレーヤは原発の閉鎖を助言されます。
マ人トレーヤによれば、飛行機など原子のパターンが妨害されると墜落します。
マ人トレーヤはいかなる人間よりも危険をよくご存じです。
マ人トレーヤの唇からますます厳しい警告と重みが発せられることを覚悟しなさい。
おれ、CASL2しかやったことないんだけど、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は死んでないと断言できる
まぁ俺は間違いなく死んでる訳だが >>367
pythonで簡単にできるような機能なんてライブラリ化されているから、自分で書くコードとしては20行もあれば終わる。 C/C++の生産性がスクリプト言語並みだし、WebアプリケーションはみんなC/C++で開発されているんだよ
このスレでの定説 >>382
このスレに書いてあることは全部素人の書いたデタラメって言っているのと同じようなもんだな(´・ω・`) >>348
例外発生してサイレントクラッシュしないだけでも意味がある。 PythonよりもC/C++をやったほうがプログラミングの勉強になるだろ。
Pythonはその後でも遅くない。 >>322
> DBのOracleがJavaに移行したのは衝撃だったな
サンマイクロを買ったら、おまけで付いてきた
オラクルが欲しかったのは、DB特化型のサーバーかな 何もしていない普通の一般人の自宅に隠しカメラを取り付け
それをネットでリアルタイム配信
仲間という人間に対する盗聴盗撮生ネット配信の会
しかけたカメラの映像
乗っ取っているPCの画像をリアルタイムで生配信中
集団で仲間の私生活を覗いて楽しんでいる
そんなことが今この国では行われています >>390
Javascriptがないという点で統計としては問題のある研究がソースだが、これを見ると言語の傾向が分かる
https://blog.sourced.tech/post/language_migrations/sum_matrix_25lang.svg
C++をGithubで最近アップロードした人間は、Pythonを次にアップロードするということ
C++からRustは少数だが、C++からJava、PHP、Rubyを次にアップロードする件数は多い >>327
Luaはコンパクト
プログラムにLuaを組み込んでも太りません。 配布されているバージョン5.1.4の tarファイル はたった212Kバイトで、
ソースコード、ドキュメントおよびサンプルが入っていて、 展開しても860Kバイトです。ソースコードは約17000行のC言語。
Linuxでは標準のLuaライブラリを含むLuaインタプリタは153Kバイトで、 Lua言語本体の実行時ライブラリが203Kバイトになります。
8bitでは走らないね
Luaはいいと思うよ。普通の使い方なら。
Cでないとしょうがないジャンルはあるね。何しろ、使いやすいアセンブラなんだから。
Cで言われてる問題は、言語構造の問題でもあるけど、CPUが根本的にかかえてる問題。
64ビットのCPUの命令を見直せば、セーフティなCになるか、より安全で高速な言語が作れる。
セーフティを求めてVM使ってる限りは、Cは生き残る
安全装置外した方が速いんだから。
CPU自体に安全装置入れろってこと >>332
Hi-Z状態は重要。XOR回路書いてみ。トランスファゲート使った方で。 >>394
負のスコアへ調整した後の結果
https://blog.sourced.tech/post/language_migrations/erik_red.png
これによるとJavaとC++、PythonでGithubに書き込むのが多いが
golangが意外に強い、むしろ圧倒的に増えてるように見える
pythonの次はgolangを書き込みのも多いように見える Pythonとか勝手にメモリ管理するほうが怖いと思わないの? javaからgolangのスコアの高さは異常値だと思うのだが、java開発者とgoの関連性が見えないな cやc++でもワンライナー行けるよね
バイナリちょっと作りたいときとか
まあinclude書くのがちょい面倒だが C/C++っいうセットにした書き方スゲー違和感ある
CとC++って別物だろ?
Cは好きだけどC++は嫌いって奴も多いだろ ライナスみたいに
なのになんでC/C++って切っても切れない仲みたいにしちゃうんだよ? コンパイラがほぼ一緒くただからじゃね?
つーか混ぜて書くのも普通だし、ccだけど実質cなのも多いし ■ このスレッドは過去ログ倉庫に格納されています