【IT】脆弱性が多いプログラミング言語、第2位はPHP - 第1位は?

1 ：田杉山脈 ★：2019/03/26(火) 23:09:23.80 ID:CAP_USER.net

WhiteSource Softwareは3月19日(米国時間)、「Is One Programming Language More Secure Than The Rest?」において、過去の脆弱性情報を集計し、どのプログラミング言語がより多くの脆弱性とかかわりを持っていたのかについて伝えた。

脆弱性情報が多い順にまとめたプログラミング言語ランキングとしては、以下が報告されている。

C言語 (47%)
PHP (17%)
Java (12%)
JavaScript (11%)
Python (6%)
C++ (6%)
Ruby (5%)

データソースはNVD (National Vulnerability Database)、各種セキュリティアドバイザリ、GitHub、そのほか人気の高いトラッキングシステムなどで集計された脆弱性情報など。対象のプログラミング言語は、過去数年間にオープンソースコミュニティで使われたプログラミング言語の中から特に人気の高いものが選択されている。

記事では、関連する脆弱性が多いからといって必ずしもそのプログラミング言語がセキュリティに対して脆弱ということを意味するわけではないと説明。例えば、C言語のシェアは50%近いが、これは長期にわたって使われていること、インフラストラクチャを構成するソフトウェアに使われており注目度が高いことなども関係しているという。
https://news.mynavi.jp/article/20190326-795188/

2 ：名刺は切らしておりまして：2019/03/26(火) 23:12:44.25 ID:lDgvFqlu.net

弱酸性に見えた俺は少し残業し過ぎかもしれない

3 ：名刺は切らしておりまして：2019/03/26(火) 23:16:02.77 ID:w8tC9gkl.net

き、脆弱性

4 ：名刺は切らしておりまして：2019/03/26(火) 23:16:20.87 ID:eXDPA1cG.net

脆弱性がない＝単に制限が多いってだけじゃないの？

5 ：名刺は切らしておりまして：2019/03/26(火) 23:22:19.33 ID:FRVSUi6T.net

PHPとか、よりマクロ的なヤツのほうが
そりゃ誰かのプログラムを呼ぶだけなんだから、
中学生が作ったC言語プログラムよりはマシだろうよ。

6 ：名刺は切らしておりまして：2019/03/26(火) 23:23:11.37 ID:DvPOBRkM.net

へー
http://9ch.net/veRcy

7 ：名刺は切らしておりまして：2019/03/26(火) 23:24:17.45 ID:4+qbEsl1.net

露骨にミスリード狙ってるなぁ
本文では言い訳してるが…

8 ：名刺は切らしておりまして：2019/03/26(火) 23:25:04.87 ID:UJrYppwo.net

年間脆弱性6000件中3000件はPHP関連だけどな

9 ：名刺は切らしておりまして：2019/03/26(火) 23:28:07.83 ID:tBfk0RU2.net

全ての道具は刃物

10 ：名刺は切らしておりまして：2019/03/26(火) 23:30:32.93 ID:YEGx3hn0.net

言語に脆弱性があるんじゃなくて、その開発環境やライブラリってことだろうな
ただ一つだけ言えるのはフリーのものは総じて対応が遅いし、アホみたいな問題が発生することが多い

11 ：名刺は切らしておりまして：2019/03/26(火) 23:31:06.11 ID:uOlS+QQR.net

Perl最強説浮上！

12 ：名刺は切らしておりまして：2019/03/26(火) 23:34:03.62 ID:O4iPbBKE.net

>>10
そうは言っても、Cは普通にガバガバだろ

13 ：名刺は切らしておりまして：2019/03/26(火) 23:35:55.16 ID:/vpgpRmg.net

まーC以外のプロトコルではほぼkernel作れないから仕方ないね

14 ：名刺は切らしておりまして：2019/03/26(火) 23:36:14.95 ID:kjHe0z6f.net

cにphpにjavaか。。
実務でシェアでっかい奴ばっかじゃん

15 ：名刺は切らしておりまして：2019/03/26(火) 23:36:37.80 ID:WFvN3MKb.net

といってもC以外の言語を駆動するインタープリタやVMはCで書かれてるわけで。
実行環境や言語仕様の安全性で言えばたぶん Java がベストなんだろうけれど
アプリケーションプログラムの品質で言えばたぶん Java がワーストだろうなぁ。
PHP は文字エンコードの取扱で深刻な脆弱性があったけどもう修正されたのかな？

16 ：名刺は切らしておりまして：2019/03/26(火) 23:38:41.97 ID:hMlM8T1X.net

過去の脆弱性情報の集計て
そりやCが圧倒的だろ

17 ：名刺は切らしておりまして：2019/03/26(火) 23:40:46.42 ID:5jFmvigU.net

>>14
ほんとにそう。
シェアが高けりゃ脆弱性の報告も多いのは当たり前で、言語由来の脆弱性があるとかいう資料じゃないのが本当に意味不明。
言語の人気ランキングと何が違うんだ？

18 ：名刺は切らしておりまして：2019/03/26(火) 23:41:10.56 ID:0dt4273I.net

Flashは？来年死ぬけど

19 ：名刺は切らしておりまして：2019/03/26(火) 23:43:51.22 ID:EulQvF49.net

そもそもPHPもJavaもCで実装されているのだが。

20 ：名刺は切らしておりまして：2019/03/26(火) 23:49:44.77 ID:Cp81k3v8.net

使われる機会が多い言語は
脆弱性情報も多くなる傾向になるだろうな

21 ：名刺は切らしておりまして：2019/03/26(火) 23:53:10.07 ID:Kdjx9xV1.net

この手のスクリプト言語ではやっぱPHPがとっつきやすい。
これで十分。

22 ：名刺は切らしておりまして：2019/03/26(火) 23:53:23.60 ID:Cp81k3v8.net

PHP,Java,JavaScript,Python,Ruby では OS やら速度が求められる機能は書けない以上
C/C++ とは守備範囲が違うし
その脆弱性を比較してもあまり意味はない

23 ：名刺は切らしておりまして：2019/03/26(火) 23:56:47.63 ID:vUZPQYsV.net

足したら104％なので、各言語ごとの集計だから
言語の本来なのか、多数波が狙われるのか

24 ：名刺は切らしておりまして：2019/03/26(火) 23:57:59.21 ID:bQIwgHpZ.net

c言語の脆弱性ってどういう意味なのかさっぱりわからん

25 ：名刺は切らしておりまして：2019/03/26(火) 23:58:03.56 ID:QhCVKYDN.net

Cに決まってら　と書き込もうとしてら
そのとおりで笑っちゃうな

26 ：名刺は切らしておりまして：2019/03/27(水) 00:02:15.50 ID:viO6G3dP.net

PHPは適当に書けば適当に動いてくれるからな

お手軽でいいんだけど、そのぶん予期しない結果になることもあるから
ある意味怖い言語でもある

27 ：名刺は切らしておりまして：2019/03/27(水) 00:11:44.71 ID:Ph0dUZcV.net

COBOL

28 ：名刺は切らしておりまして：2019/03/27(水) 00:14:14.13 ID:zryLjFFD.net

>>25
当たり前だよな
・シェアが大きい
・OSやデバイスドライバなど脆弱性が入り込みやすい用途でもちいられる

こんな調査に何の意味があるのかと…
(PL/Iは著しく脆弱性が少ないとか言いたいのかな？)

29 ：名刺は切らしておりまして：2019/03/27(水) 00:20:29.72 ID:s8ZkHVr4.net

Python (6%)
C++ (6%)
Ruby (5%)
って笑える。ＪＡＶＡやPHP以上に問題あるよ

30 ：名刺は切らしておりまして：2019/03/27(水) 00:20:38.89 ID:QblVzPcv.net

生PHPのサイトなんて脆弱性だらけだからな
かと言ってフレームワークはロクなもんがない
PHPは滅びたほうが世のため

31 ：名刺は切らしておりまして：2019/03/27(水) 00:21:17.12 ID:EKjyuCMU.net

>>25
c言語自体に脆弱性はない気するんだがなー
結局、コンパイラとかosの問題に帰結する気がする

32 ：名刺は切らしておりまして：2019/03/27(水) 00:36:31.57 ID:BpuGQinz.net

マックにはウィルスが少ないので安全、というのと同じ。

33 ：名刺は切らしておりまして：2019/03/27(水) 00:38:14.45 ID:3+iOrAsO.net

C言語を一番長く利用してきたので書きたい事が多くあるんだが眠い。
どんな言語でも弱点はあるけどC言語はすぐ作れるようになるので結果的に脆弱性を生みやすい？

34 ：名刺は切らしておりまして：2019/03/27(水) 00:44:21.82 ID:lW8+/A69.net

>>10
Cをやってるやつらが脆弱性の塊ってことだろうな。
むりするなよ。できないこともあるから。

35 ：名刺は切らしておりまして：2019/03/27(水) 00:46:40.61 ID:EQ9LkgSJ.net

Cはバッファオーバーフロー攻撃とか効く言語だ
そしてまあまあ他の言語より書くのに神経を使う部分がコードの本質より別のことに割くから
そして沢山使われてれば攻撃も多いし、苛烈

---

2nd にペチパー無様ｗ
ペチパー　ペチパー　と煽られるだけはある

36 ：名刺は切らしておりまして：2019/03/27(水) 00:58:41.05 ID:xekR5adr.net

良い子のみんな、ゴキブリ韓国人を見てごらん
　ちゃんと勉強しないと、ああなっちゃうんだよ
悪い子のみんな、悪いことばかりしていると
　ゴキブリ韓国人に生まれ変わるんだよ

37 ：名刺は切らしておりまして：2019/03/27(水) 01:03:39.13 ID:CBXq5Oki.net

>>35

gccだと-fstack-protectorと-D_FORTIFY_SOURCE=2フラグを忘れずつければ良いが忘れるのは簡単だ

38 ：名刺は切らしておりまして：2019/03/27(水) 01:08:25.18 ID:CBXq5Oki.net

>>29

スクリプト言語の脆弱性は言語のメンテナンスチームの質や設計による
PHPのセキュリティ脆弱性は段違いに酷い
商用向けならセキュリティのコンサルなりに見せないと安心できない

39 ：名刺は切らしておりまして：2019/03/27(水) 01:14:19.79 ID:gWkgHZm3.net

javaって制御系では使えませんと明記されていたから
Cで組んだけど。制御系はやばいからjavaあかんって事なんだろうけど。

40 ：名刺は切らしておりまして：2019/03/27(水) 01:16:56.43 ID:6WSjQf2C.net

見出しがおかしいな
言語に脆弱性があるわけじゃないだろう

41 ：名刺は切らしておりまして：2019/03/27(水) 01:24:18.73 ID:8VJGHziz.net

というか、そんなほかの言語ときちんと比較できるほど知っている人っているんかいな？
俺はJAVAしかわからん

42 ：名刺は切らしておりまして：2019/03/27(水) 01:28:54.01 ID:MgNFXA8p.net

その言語で作り
その言語の言語処理系でコンパイルしたり、スクリプト実行したり
そういう各種システムの脆弱性情報を集めて
それを言語別に集計しました
みたいな話なんだろうな

43 ：名刺は切らしておりまして：2019/03/27(水) 01:30:21.24 ID:OY570tm1.net

>>39
GC が動き出すと予期せず動作が遅れることがあるのでリアルタイムの制御には向かない。
セキュリティの問題ではないよ。
そういう分野では GC のない C/C++ しかない。

44 ：名刺は切らしておりまして：2019/03/27(水) 01:39:00.18 ID:7F+uCqAA.net

ちゃんと書けてるつもりでも書けてないんだよ
プログラムなんてだれでも書けるんだというやつは
落とし穴にハマりながら言ってることに気が付いてない

45 ：名刺は切らしておりまして：2019/03/27(水) 01:48:20.46 ID:0yCUW7m+.net

自分は今、ピクセラ社の、　Station　TVというのでテレビをPCで見ているが、　Microsoft　Visual　C++　というのがないと強制終了する。絶対にあかない。
コレはあれこれ　自分自身で試行錯誤して　見つけた。　　OSを回復や再インストール後、コレを入れてｋら、このアプリを入れないと、起動しない

46 ：名刺は切らしておりまして：2019/03/27(水) 01:48:51.61 ID:ZoSgEw0e.net

>>44
システム開発、サービス開発という業務においてプログラミングはそこまで重要じゃないということを知ってる人が案外少ないんだよね。
分からない人から見るとプログラミングできること自体がすごく見える（機械と会話できる）みたいなんだけど、
ライフサイクルや事業計画にアジャストしたプログラミングを書くことが容易ではないのであって、
プログラミングそのものは難しくないということが分かっていない。

ただプログラミングするだけならレベルにもよるけど一ヶ月もあれば誰でも出来ることなのよねｗ
この話は「ただ英語を話せるだけの人」を連れて来ても事業上のメリットはあまり得られないことと近しいと思う。
「英語ペラペラの人を採用しました！」「じゃあ、事業の海外展開も順風満帆だね！」
そんなアホな考えをする人はいないだろって話ｗ

47 ：名刺は切らしておりまして：2019/03/27(水) 01:55:18.39 ID:LKvwOV7p.net

>>46
コンサルに騙されたのか？

48 ：名刺は切らしておりまして：2019/03/27(水) 02:07:07.18 ID:7F+uCqAA.net

>>46
高レイヤーでちょっとスクリプト言語かじった程度の認識だね
動くだけソフトウェアやサービスなら素人がコピペでも作れるよ
そんな自称プログラマが作ったソフトウェアやサービスが山ほどあるね
不特定多数が利用するウェブアプリケーションなんて被害が顕著であちこちで情報流出が絶えない
さらに新しいアプリをそのゴミコードをベースにコピペで作るもんだから脆弱性をバラまいてることに気が付かない
まあ使う人間が限られたソフトウェアやサービスならバグがあろうが脆弱性があろうがかまわんだろうがな

49 ：名刺は切らしておりまして：2019/03/27(水) 02:14:47.46 ID:BulSUrGq.net

Cのライブラリに脆弱性見つかって狙われるのはそれを利用しているサーバ上のphpだったりするよね

50 ：名刺は切らしておりまして：2019/03/27(水) 02:16:53.66 ID:3Jj3OJws.net

Perlならちょっと書ける

51 ：名刺は切らしておりまして：2019/03/27(水) 02:25:48.64 ID:xekR5adr.net

韓国人のやり方
●善人面で日本人に接近しろ。
●片言の日本語を一生懸命に喋れば、日本人は善人と信じ込む。
●日本を韓国文化で浸食しろ 。
●日本文化に「韓国発祥だ！」と言いがかりを付けろ。
●韓国の歴史観を否定する者は、土下座するまで恫喝しろ。
●「韓日併合は植民化までの通過点に過ぎない。」と主張しろ。
●日本人に なりすまし、世界中で悪事を働け。
●韓国アプリ「ＬＩＮＥ」で日本人の個人情報を盗み取れ。
●国際ＩＴ企業に潜り込み、内側から支配しろ。
●世界中の韓国系・中国系・ユダヤ系と連携して日本を叩け。
●「日本＝ナチス、韓国人＝迫害されたユダヤ人」と世界中で同一視させろ。
●韓国の失業者を日本へ大量移民させろ。
●移民は最強の侵略兵器。大量に入れて日本を植民化しろ。
●日本の右翼に成りすませ。日本の左翼を援助しろ。
●日本へ陰湿な嫌がらせを繰り返せ。
●危険な毒食品・不良製品を日本へ大量輸出しろ。 　
●日本の神社に放火しろ。神仏を破壊しろ。御神木を薬物で枯らせ。
●エイズにかかったら、日本へ行け。日本人とヤリまくり、病気をバラ撒け。
●対馬の土地を侵略目的で買い漁れ。
●日本にグローバリズムを植え付けろ。韓民族のナショナリズムは守り抜け。
●日本人に親切にする事は、見返り狙いの「先行投資」である。
●反日はどんな苦痛も和らげる万能薬。

52 ：名刺は切らしておりまして：2019/03/27(水) 02:33:02.57 ID:CBXq5Oki.net

>>46
>ライフサイクルや事業計画にアジャストしたプログラミングを書くことが容易ではないのであって、

事業の内容にもよるがプラットフォームに近いレベルにいくと、三流人材がハリボテを実装してしまうと後続の競合他社が高速に追加機能を実装し
さらに遅延などによってユーザーに見放されるか、サーバー代・消費電力が馬鹿にならなくなって詰むことになる

53 ：名刺は切らしておりまして：2019/03/27(水) 02:37:45.34 ID:CBXq5Oki.net

@RKX1209
イノベーションの先生「昔カノープスって会社を作ってグラフィックアクセラレータを開発して
世界トップの売り上げを更新した。当時のNVIDIAと性能差を圧倒的につけられたのはデバイスドライバの質で...
その後上場してグラスバレーに買収されたよ」 僕((すす…

toshi_noP （としの@事務員ドールP）
当時32ビットのリエントラントなデバイスドライバをアセンブラで書ける人って、カノープスとNECに
1名ずつしか居なかった日本。 他はリファレンスのドライバをそのまま添付するしか無くて性能以前だった。

54 ：名刺は切らしておりまして：2019/03/27(水) 02:39:22.81 ID:CBXq5Oki.net

ビル・ゲイツ「優秀なソフトウェア・プログラマーは平均的なプログラマーの10,000倍の価値がある。」

http://tracpath.com/works/story/high_performance_computing_programmer/

「優秀な旋盤工の賃金は平均的な旋盤工の数倍だが、優秀な
ソフトウェア・プログラマーは平均的なプログラマーの10,000倍の価値がある。」

55 ：名刺は切らしておりまして：2019/03/27(水) 02:41:46.65 ID:WQWpD91R.net

>>46
> ただプログラミングするだけならレベルにもよるけど一ヶ月もあれば誰でも出来ることなのよねｗ

ただ野球するだけならレベルにもよるけど3日もあれば誰でも出来ることなのよねｗ
草野球レベルと、プロ野球レベルを同列に語るバカ。

野球のルール同様、Cなんて言語仕様は簡単だよ。他の言語と違って、本来標準
ライブラリはなくても作れるものだし、車輪の再発明の手間さえ厭わなければ、
必ず標準ライブラリを使う必要もない。

56 ：名刺は切らしておりまして：2019/03/27(水) 02:47:13.31 ID:WQWpD91R.net

昨今のスクリプト書きのゆとり世代は、「本物のプログラマはPascalを使わない」
(原題:Real Programmers don't write Pascal)とか、知らんのだろうなぁ。

57 ：名刺は切らしておりまして：2019/03/27(水) 03:03:56.30 ID:+8zexJm5.net

C言語以外では無駄な処理を強要されてるってこと

58 ：名刺は切らしておりまして：2019/03/27(水) 03:15:33.97 ID:my0g/eCF.net

cはマルチスレッドで困る。あと、文字列処理が糞めんどい。

59 ：名刺は切らしておりまして：2019/03/27(水) 03:19:56.53 ID:dJ5BlesR.net

セキュリティのためには型推論＋LLVMでネイティブコンパイルできる系言語が
もっと普及すべきだけど群雄割拠だしそこまで要求されることが少なくてなかなかシェアを取る言語が出てこない

60 ：名刺は切らしておりまして：2019/03/27(水) 03:27:21.73 ID:DnNZCT2p.net

コボルって果実が美味いらしい。
熟してるらしい。

61 ：名刺は切らしておりまして：2019/03/27(水) 03:38:55.67 ID:gm4ZWNhF.net

>>28
正論。
記事書いたやつ馬鹿すぎ。

62 ：名刺は切らしておりまして：2019/03/27(水) 03:54:33.74 ID:QufrfUWY.net

>>28 ID:zryLjFFD
>>25
>> 当たり前だよな
>> ・シェアが大きい
>> ・OSやデバイスドライバなど脆弱性が入り込みやすい用途でもちいられる
統計数値の誤用の例
利用頻度の高い言語ほど事故も多くなる。
言語の脆弱性？
脆弱性の事故件数÷利用頻度で比較しないと意味がないのに。。。
特にC言語はマクロアセンブラに1対1に対応可能なんだからC言語の脆弱性
って何なんだろうか？

63 ：名刺は切らしておりまして：2019/03/27(水) 04:36:55.48 ID:dJ5BlesR.net

C言語はバッファーオーバーランが起きやすい言語仕様というところかな…
プログラマーが完璧なら問題が起きないけどそれもあり得ないからな…

64 ：名刺は切らしておりまして：2019/03/27(水) 04:52:04.23 ID:LV3A+cu7.net

・言語そのものに脆弱性がある
・その言語で作られたフレームワークやライブラリに脆弱性がある
・その言語で作られたアプリ、プログラムに脆弱性がある
この３つ分けて考えたほうがいいのでは？

65 ：名刺は切らしておりまして：2019/03/27(水) 07:13:01.50 ID:SKgfjv2z.net

ActionScript...

66 ：名刺は切らしておりまして：2019/03/27(水) 07:47:06.67 ID:CnmWw2GL.net

CはメモリーAPで管理できるからだろうけど

67 ：名刺は切らしておりまして：2019/03/27(水) 07:49:57.31 ID:Gn04YQUj.net

フレオっていうサイト作成ツールがPHP5なんだけど使わない方がいいんかな

68 ：名刺は切らしておりまして：2019/03/27(水) 07:50:14.76 ID:FcHejdYL.net

G7サミット国が母語とした自然言語ですと
論理的なドイツ語は堅固性が高く、情緒的な日本語は脆弱性が高いと思う
いい代えれば、脆弱性の高さが「玉虫色」の解釈を許すということ
文脈次第でどのようにも読解できるということ

日本の腹芸政治家が良く使う言葉そのものですな〜

69 ：名刺は切らしておりまして：2019/03/27(水) 07:53:30.92 ID:FcHejdYL.net

これから進展するAIシステムがもっとも不得意とする世界だろうね
まるで「禅問答」か公案問答集のようなものだ

コマンドがファジー
文脈もファジー

ハイ、ハイパーテキストを瞬時にして解釈できる
最近流行りの「コミュニケーション」能力の最高峰になる

70 ：名刺は切らしておりまして：2019/03/27(水) 07:54:18.11 ID:xuNqP268.net

>>1
母数でわらんと意味内
ｃは割合的には大したことなさそう

71 ：名刺は切らしておりまして：2019/03/27(水) 07:57:07.58 ID:FcHejdYL.net

人工言語の進展が、実は・・・自然言語から本来内包していた「巧みさ」を奪ってます
つまり、自動車に頼るがあまり足が萎え弱い人物になるように
電脳に頼り過ぎて、人として高度な交接が不能になるとは何とも嘆かわしい風潮に成るかもｗ

72 ：名刺は切らしておりまして：2019/03/27(水) 08:00:15.58 ID:FcHejdYL.net

人工言語の議論は、釣り師がどんな装備で目的の魚を釣り上げるか
この議論に近い

所詮、人間が自然言語を模倣して構築した人工言語である以上
常に「自然言語＞＞＞人工言語」となるでしょうね
もし、これが完全に逆になったときが、電脳に人類が完敗する瞬間

73 ：名刺は切らしておりまして：2019/03/27(水) 08:02:15.89 ID:0KUQjn0T.net

>>8
ソースは？

74 ：名刺は切らしておりまして：2019/03/27(水) 08:03:14.30 ID:j+kLcUyW.net

Cをディスる Pythonエンジニアっているけど
VBAでドヤ顔してるおっさんと同じ人種

75 ：名刺は切らしておりまして：2019/03/27(水) 08:11:02.83 ID:GA8jrJlf.net

これが一番の近道だよ。^^

http://p.booklog.jp/users/haseham

76 ：名刺は切らしておりまして：2019/03/27(水) 08:12:00.99 ID:FcHejdYL.net

C言語の開発は、ATT社のベル研究所
ここは戦後、トランジスター開発でノーベル物理学賞をゲットしたショックレー一派とか
世界一の物理学関係の有識研究者の巣窟で、通信システムの制御に最適化された言語
AとBがこれ以前に開発され、その完成版としてC言語をこの世に出しました
この言語で、UNIXが構築、したがって通信システムには、こいつが一番しっくり来ます
UNIXをもっと簡便にしたのがLINUX、UNIXカーネル（幹）はソースコードが公開されてるいて
方言だらけで、オープンソースの真骨頂を行ってるOSになる

したがって、この言語の得意とするのは「制御」系

77 ：名刺は切らしておりまして：2019/03/27(水) 08:12:31.22 ID:EUx9f41y.net

何年経ってもオブジェクト志向がわからんおっさんが通りますよ

78 ：名刺は切らしておりまして：2019/03/27(水) 08:13:22.39 ID:FcHejdYL.net

言語は、自然も人工もシンプルでオーソドックが一番安定していてレスポンスも速い

79 ：名刺は切らしておりまして：2019/03/27(水) 08:14:44.48 ID:FcHejdYL.net

中央演算装置に直接対応したアセンブラから入って、次がC言語
これが一番、深いレイヤの理解に繋がると思う

80 ：名刺は切らしておりまして：2019/03/27(水) 08:16:22.55 ID:FcHejdYL.net

スクリプト言語は「脚本」
オブジェクト言語は、その脚本を支える「文脈」

81 ：名刺は切らしておりまして：2019/03/27(水) 08:17:07.65 ID:FcHejdYL.net

スクリプト言語を駆使したければオブジェクト言語に精通しなければ使い物にはならんと思うが如何？

82 ：名刺は切らしておりまして：2019/03/27(水) 08:21:11.83 ID:lswRK7gy.net

PHPで、脆弱性を全部潰して実装するの、えらく大変だったなあ
10年前の話だけど

83 ：名刺は切らしておりまして：2019/03/27(水) 08:30:06.72 ID:8ZgUCJj+.net

PHPもPythonも同じだろ
Cが別格なのはわかるけど…

84 ：名刺は切らしておりまして：2019/03/27(水) 08:34:27.49 ID:LIsn+41K.net

CやPHPみたいに自由度が高い言語は書くやつがヘタクソだといくらでも脆弱になる。使う人の問題だろ。

85 ：名刺は切らしておりまして：2019/03/27(水) 08:41:59.96 ID:eA4vJPwz.net

Cは意図的にガバガバ
PHPは意図的にガバガバ

86 ：名刺は切らしておりまして：2019/03/27(水) 08:46:18.42 ID:OTGGcEZg.net

PHPは簡単に使えるのでレベルが低いエンジニアによるミス
C言語は難しいので使い方がわからないレベルの低いエンジニアによるミス
結局レベルの低いエンジニアのせいやな。

87 ：名刺は切らしておりまして：2019/03/27(水) 08:56:34.22 ID:6Zl2jDVC.net

>>79
アセンブラで計算機を
Lispで計算を学ぶのがいいと思う

88 ：名刺は切らしておりまして：2019/03/27(水) 08:59:04.76 ID:R9CPI3Ic.net

どの言語も同じだろ。結局は予算次第。
カネがないから低能プログラマーを安く使ったり、
脆弱性のチェックをしないで納品する。
そして検収でも気づかないので後々直せと言われたら代金を請求して直す。
その金を最初から出せばいいのにケチるから・・・

89 ：名刺は切らしておりまして：2019/03/27(水) 09:00:54.56 ID:eiv+Aer6.net

入口はPHPと思う。Wordpressがメジャーなんで、ここからの攻撃が極めて多い。

Cは無数にプログラムが転がってるし。
脆弱性云々以前に作られたプログラムはそんなのお構いなし。

90 ：名刺は切らしておりまして：2019/03/27(水) 09:01:58.62 ID:6JPVrqo8.net

　


こんなもん、普通に考えて利用機会シェアに比例するに決まってるジャンｗ


　

91 ：名刺は切らしておりまして：2019/03/27(水) 09:09:54.80 ID:17vy8XDr.net

言語に脆弱性があるって意味がよく分からない俺
どういう事だってばよ

92 ：名刺は切らしておりまして：2019/03/27(水) 09:13:07.35 ID:+TSz+MyH.net

シェア順にも見える

93 ：名刺は切らしておりまして：2019/03/27(水) 09:17:54.61 ID:lwSEFg56.net

アセンブラに近いだけだろ

94 ：名刺は切らしておりまして：2019/03/27(水) 09:39:19.28 ID:iagrtmcD.net

タイトルが嘘なのでフェイク記事だろ

95 ：名刺は切らしておりまして：2019/03/27(水) 09:51:36.86 ID:dJ5BlesR.net

>>88
とはいえ、型の部分でポインタむき出し、自動キャストをしてしまう
C言語は致せりつくせりの高級言語に比べてセキュリティ面で不利
PGのレベルが低くても他言語なら何とかなっていたケースというのはあると思う

C言語は使う範囲を狭めて局所的な速度最適のためだけに使うほうがいい

96 ：名刺は切らしておりまして：2019/03/27(水) 10:17:38.64 ID:mFs2aiP7.net

C言語なんてレガシーアプリだけだろ。
今はC++

つか、脆弱性言うんなら、一番危険なのはアセンブラ。

97 ：名刺は切らしておりまして：2019/03/27(水) 10:47:58.86 ID:my0g/eCF.net

>>96
組み込みでは現役ですお

98 ：名刺は切らしておりまして：2019/03/27(水) 11:18:08.33 ID:LIsn+41K.net

>>96
自動車の中で動いてる数百のコンピュータはほとんどCだぞ

99 ：名刺は切らしておりまして：2019/03/27(水) 11:32:40.37 ID:xekR5adr.net

良い子のみんな、ゴキブリ韓国人を見てごらん　　
　ちゃんと勉強しないと、ああなっちゃうんだよ
悪い子のみんな、悪いことばかりしていると
　ゴキブリ韓国人に生まれ変わるんだよ

100 ：名刺は切らしておりまして：2019/03/27(水) 11:35:24.01 ID:eFvZyibc.net

よく使われてる言語ランキング

101 ：名刺は切らしておりまして：2019/03/27(水) 11:46:18.27 ID:SYa7tAhz.net

過去の統計だと、こんなもんか
だが、メモリーリークへの安全性が保証されてないこれらの言語など、もはやセキュリティ目線だと論外
go-langかrust使え

102 ：名刺は切らしておりまして：2019/03/27(水) 11:49:42.94 ID:vYLdXUGg.net

言語としての脆弱性ではなく、過去に報告のあった事例の数でのランキングなんだから
より普及していてより古い言語ほどランキング上がるだけじゃん。

103 ：名刺は切らしておりまして：2019/03/27(水) 11:56:13.88 ID:di3dI1ih.net

>>96
（ｷﾘｯ
が抜けてるぞ？

104 ：名刺は切らしておりまして：2019/03/27(水) 11:56:20.87 ID:vYLdXUGg.net

>>96
ところがだな、C言語で募集してるゲーム会社があって、
行ってみたらほんとにCで作ってたってのがあってだな。
せめてC++使いましょうよって言ったら「呼び出しにオーバーヘッドがかかるから却下」
って言われたんだと。
そこはMSDOS時代からゲーム作ってる社長が現役プログラマーもやってて
そういう時代の変化についていけない老害が実権握ってるとこはまだまだ多いよ。

105 ：名刺は切らしておりまして：2019/03/27(水) 12:27:37.72 ID:4y9ZHWjE.net

自由度が高い言語ほどそうだろうな

106 ：名刺は切らしておりまして：2019/03/27(水) 12:56:32.28 ID:LKYKKGxO.net

システム運用してたら上がってくる脆弱性情報ってほとんどJavaなんだが

107 ：名刺は切らしておりまして：2019/03/27(水) 13:04:12.88 ID:MTF19U/Y.net

>>104
C++の呼び出しオーバーヘッドって、何をわかって言ってるんだろうな？

インスタンス生成時のコンストラクタ呼び出しならクラス設計次第だし、ファイルや
ウィンドウのハンドルをメンバ変数として保持している程度なら、コンストラクタでの
初期化コストなんてほぼゼロだし。

局所変数をどこでも自由に宣言できるからと、forループ内でオブジェクトを宣言して、
ループ回るたびにコンストラクタ呼び出しされているとかか？

専門卒の50代現役だけど、ぜひ講釈を聞いてみたい。

108 ：名刺は切らしておりまして：2019/03/27(水) 13:39:29.65 ID:NiAsoJLd.net

リソース公開するから悪いんだろう

109 ：名刺は切らしておりまして：2019/03/27(水) 13:43:29.96 ID:8xy2djdX.net

>>107
言うとおり。cだろうがc++だろうが本質的には変わらない。cだってforでヒープ確保しまくりならコストかかるし、大したことないが…
それよりシステムコールのほうがよっぽど待たされる。ノンブロッキングで設計とかしてるとね。

110 ：名刺は切らしておりまして：2019/03/27(水) 13:51:19.06 ID:pUcWhdkZ.net

こんなん、ニュース価値ないんじゃないの。
１％でも工数の割に期待金額とか高ければ、悪いプログラムもつくれるから

111 ：名刺は切らしておりまして：2019/03/27(水) 14:05:39.27 ID:dJ5BlesR.net

でも、現実にRustを使っているからセキュリティがレベルが高い（ｷﾘｯてミドルウェアが出てきているからな

こんなのとか

Firecracker ? サーバーレスコンピューティングのための軽量な仮想化機能
https://aws.amazon.com/jp/blogs/news/firecracker-lightweight-virtualization-for-serverless-computing/

Firecrackerは最小限主義の流儀で造られました。 私たちはオーバーヘッドを減らし安全なマルチテナンシーを可能にするために、
crosvmからスタートし、最小限のデバイスモデルを設定しました。

FirecrackerはRustで書かれており、その最新のプログラミング言語はスレッドの安全性を保証し、
セキュリティの脆弱性を引き起こす可能性があるさまざまなタイプのバッファオーバーランエラーを防止します。

112 ：名刺は切らしておりまして：2019/03/27(水) 15:05:20.90 ID:SYa7tAhz.net

>>111
セキュリティを重視するのか、生産性を重視するのか、確保できる兵隊の数を重視するのか、開発対象によって異なるわな
システムプログラミングならセキュリティでRust、Webアプリなら生産性でjsかPython、受託SIなら兵隊数でJava一択

113 ：名刺は切らしておりまして：2019/03/27(水) 15:12:16.28 ID:lG5hDiH2.net

Cが超古い言語なのにね

114 ：名刺は切らしておりまして：2019/03/27(水) 17:20:14.05 ID:CBXq5Oki.net

>>111

まずスレッド安全性を脆弱性と呼ぶのは語弊がある
一般論としてCでもスレッド安全性を追求すれば簡単にできるが、コードできるレベルにないなら標準外のスレッドライブラリーを使えば良い
（pthreadのことではない、ちなみに標準以外のライブラリーはCSの学生には学習範囲を制限・狭めるため薦めない）
いずれにしてもスレッドはローレベルでかなり早くできるので、ライブラリーに投げるのは望ましくない

それとこのマイクロVMはシングルCPUで何個もインスタンスを作ることを想定している
そのためマルチスレッドアプリケーションを動かしてもパフォーマンス向上の余地はおそらくないだろう

KVMをカーネルスペースに使っているからレスポンスが早く、実装面でも軽いのは当たり前として、安全といってる理由のレベルが違う
KVMのエミュレーション脆弱性を分離・仮想化することで、セキュリティレベルが高いと主張しているので、ローレベルの設計によってセキュリティを高めるしかないため、言語がセキュリティを高めているわけではない

PIC/APIC/IOAPIC/PITの機能には無駄なものが多いから、最低限のAPIC機能だけをKVMでサポートするのが早く安全であることは知られており、新しいアプローチではない
（ソースコードはチラ見程度なので、誤解している可能性はある）

115 ：名刺は切らしておりまして：2019/03/27(水) 18:04:58.96 ID:CBXq5Oki.net

>>112
>システムプログラミングならセキュリティでRust、Webアプリなら生産性でjsかPython、受託SIなら兵隊数でJava一択

Rustのセキュリティが強いというのは誇張だ
Cならメモリーディテクター・プロファイラー/アナライザーやコンパイラのチェック機能を使えば良いだけだ。Cはハードウェア側の事情で使わないという選択はない
C++にはスマートポインターがあり心配ならばメモリーディテクターを使えば良い

Web周りであればgolangもある
バックエンドは速度が求められるため、（セキュリティは最悪だが）PHPが使われることはある。Pythonはパフォーマンスが必要な用途だと遅すぎる
JSはバックエンドとしては癖が強い
JavaやC#の最近のバージョンであれば安全性やパフォーマンス、ライブラリーの集積があるためWebにも十分に使える

116 ：名刺は切らしておりまして：2019/03/27(水) 19:08:55.55 ID:hHgEdP5T.net

>>107
ポリモフィック使ったらメンバ関数呼び出しが関数テーブルの間接参照になってパイプラインストールの元だからな。

117 ：名刺は切らしておりまして：2019/03/27(水) 19:37:15.22 ID:1NfaY++X.net

誰でも頭が良くなる、プログラムが書けるようになる方法が発見される 67738
https://you-can-program.hatenablog.jp

118 ：名刺は切らしておりまして：2019/03/27(水) 19:53:59.02 ID:As3SPDPm.net

Lisp系ないのか

119 ：名刺は切らしておりまして：2019/03/27(水) 20:01:31.05 ID:tIR+hF6T.net

char *s;
scanf("%s",s);

ヨシ

120 ：名刺は切らしておりまして：2019/03/27(水) 20:13:54.56 ID:/8ffRo+K.net

>>119
ガッ

121 ：名刺は切らしておりまして：2019/03/27(水) 20:24:11.61 ID:WQWpD91R.net

>>116
シッタカ乙。組込のワンチップマイコンでもない限り、WindowsやLinux前提の
システムなら、複数プロセス・複数スレッドが同時に多数走っていて、タスク切替
に伴うコンテキストスイッチも常に発生しているので、呼び出す関数内の実処理が
カラッポならいざ知らず、たかだか関数呼び出しがテーブルの間接参照呼び出し
になる程度など、問題にならんわ。

122 ：名刺は切らしておりまして：2019/03/27(水) 20:30:40.04 ID:qu8v97/1.net

>>119
ブスえら〜

123 ：名刺は切らしておりまして：2019/03/27(水) 20:57:02.23 ID:af1Fhh+a.net

つまり Whitespace や なでしこは堅牢な言語ってことだな

124 ：名刺は切らしておりまして：2019/03/27(水) 21:53:53.15 ID:TpyaW1sF.net

>>121
横からだが、ゲームはある意味組み込み系に近いからな
スレッドは時分割なんかじゃなくて、任意のタイミングで自分で切り替えるもの
Windows3.1のスレッドに近い

125 ：名刺は切らしておりまして：2019/03/27(水) 22:04:36.32 ID:FQzRMcxy.net

純粋に書くのはログインだけで
後はDBをjsonでjsとやり取りする時代たぞ。

126 ：名刺は切らしておりまして：2019/03/27(水) 23:01:33.92 ID:razZmuPf.net

まあCはしゃーない
殿堂入りだから
でもさあ
C++より多いJavaとPHPは何なの？

127 ：名刺は切らしておりまして：2019/03/27(水) 23:33:18.72 ID:BulSUrGq.net

>>116
いや、実関数のアドレスが変わらない限りBTBでストールは起きない

煩雑に実関数のアドレスが代わるような場合は同じ事を関数テーブルで実現するにしろ、多段の分岐でするにしろ結局はストールする

128 ：名刺は切らしておりまして：2019/03/28(木) 00:10:15.27 ID:9F23h/tM.net

自由度の高い言語は、きちんと管理しないと暴走します

129 ：名刺は切らしておりまして：2019/03/28(木) 00:12:17.45 ID:9F23h/tM.net

>>88
君は、馬鹿？

全然違う

130 ：名刺は切らしておりまして：2019/03/28(木) 10:15:56.68 ID:uN5Em0vN.net

>>114
メインは設計、つまり言語非依存の部分でセキュリティを確保しているけど、
バッファオーバーランは言語によってセキュリティが向上する部分だろ

131 ：名刺は切らしておりまして：2019/03/28(木) 18:03:12.66 ID:OdoIMOT4.net

>>124
今どきのハードウェアでも、ゲームはメーカーとかが用意したAPI経由じゃなくて
直接ハードウェア叩いてるの？

132 ：名刺は切らしておりまして：2019/03/28(木) 18:44:10.18 ID:uN5Em0vN.net

>>131
Unityで>>124みたいな非プリエンティブマルチタスクみたいなことをやっている
もっとマルチスレッドなゲーム開発環境があってもいいと思うけどな

133 ：名刺は切らしておりまして：2019/03/28(木) 18:49:59.08 ID:z58yBklL.net

>>131
直接叩けたのは PS2 辺りまでだね
ハードウェア仕様変更に対応できなる恐れがあるから後期では禁止か非推奨になってたと思うけど

134 ：名刺は切らしておりまして：2019/03/28(木) 19:23:52.05 ID:NDtCFsWg.net

>>56
pascalなんてC言語の前身みたいなもの。
「本物のプログラマならC言語は使わない」と言い換えても差し支えない。
Cを奨める似非プログラマの多いこと多いこと。

135 ：名刺は切らしておりまして：2019/03/28(木) 19:50:01.88 ID:z58yBklL.net

>>107
何百何千というオブジェクト(数十種類)に対して毎フレーム Update 関数(仮想関数)呼び出すと地味に処理負荷を食う

仮想関数経由での呼び出しを減らす最適化を行うことも実際にある

1ms 2ms を削りたい場面が出てくるゲームならではの話やね

136 ：名刺は切らしておりまして：2019/03/28(木) 21:24:37.37 ID:YIWVKn8f.net

>>135
3Dモデリングのアプリなら判らんでもないが、たかだかゲームごときで何千の
オブジェクトはねぇだろ。　第一、3D描画やテクスチャ処理の大半は、ビデオ
カードに丸投げだろ。　日本のゲームとかほぼ紙芝居だし。　話盛り過ぎ。

1ms単位で削りたいなら、アセンブラで書いたら？(w

137 ：名刺は切らしておりまして：2019/03/28(木) 23:23:46.52 ID:wKYsWRfp.net

>>136
上で書いたオブジェクトはいわゆるゲームオブジェクトと呼ばれるもので、ゲーム中にゲーム固有の振る舞いをさせる為に実装するもの(移動、AI、定型的な動き演出など)
描画関連のオブジェクトやリソースは全く別

画面に表示する可能性のある3Dオブジェクトはシーン中に数千から万越えは珍しく無いし、パーティクルだとその数は更に増える


> 1ms単位で削りたいなら、アセンブラで書いたら？(w

SIMD 命令は intrinsics を使うので最適化のためにアセンブラでコードを書くことはまずない
非効率なコードが生成されていないか逆アセンブルされたコードを確認することが稀にあるくらい

FF15みたいな有名タイトルだとこうやって具体的な内容も表に出てるし、かなり細かな最適化をたくさんしている
自分が書いた程度の内容で話を盛ってるとか思われるのは心外だよ
http://jp.gamesindustry.biz/article/1609/16090501/

138 ：名刺は切らしておりまして：2019/03/28(木) 23:39:06.24 ID:0TfTu7oI.net

仮想関数呼び出しってCで同じことやろうとしたら結局インスタンスごとに分岐や関数ポインタ使うことになって同じ時間かかるだろ？
まあ予測当たるように大まかにソートしておくとかすればいいんだが
仮想関数だろうがやることは変わらない

139 ：名刺は切らしておりまして：2019/03/29(金) 01:17:12.69 ID:mSIcBnru.net

>>131
ハードにもよるけど、例えばDSは、SDKはあったけど、Vブランク割り込みとかは、普通にコールバックで受け取って処理してたね

140 ：名刺は切らしておりまして：2019/03/29(金) 01:29:45.28 ID:mSIcBnru.net

>>132
プリエンティブなスレッドは、バグの再現性の低いバグが出たときに全然追えないからなー
世の中にはコルーチンですらまともに排他制御できない人もいるからね、、、

でも、最近のUnityはやっと高速化にも力を入れはじめて、キャッシュヒットを考慮した作りにしたり、ワーカースレッドに処理を逃がす仕組みを作ったり、精度が低いけど高速な数学関数用意したりして

141 ：名刺は切らしておりまして：2019/03/29(金) 08:04:13.22 ID:6xiq0O+r.net

>>138
関数テーブルでやらんでもいいだろと。
条件分岐の羅列でもなんでも

142 ：名刺は切らしておりまして：2019/03/29(金) 10:27:16.34 ID:WUMSGBjO.net

>>141
分岐の羅列でも関数テーブルでも分岐予測が外れたらストールするのは同じ
逆に予測が当たるならテーブルの方が命令数減るぶんだけ速くなる。
実データが一種類ならBTBで常に予測が成功するからね

143 ：名刺は切らしておりまして：2019/03/29(金) 14:30:56.63 ID:I/+3HlMa.net

【速報】金券500円分タダでもらえる　　
https://pbs.twimg.com/media/D2zNwP2UwAARLRa.jpg　　　　
　　　
�@スマホのApp Storeから「タイムバンク」をインストール（iOS、Android両バージョンあります）　　　
�A会員登録　　
�Bマイページへ移動する。　　　
�C招待コード→招待コードを入力する [Rirz Tu]（スペース必要無し）　　　　　
　　　　
コードを入力した方に600円もらえます　
今なら更に500円ギフト券を貰った残高からただで買えます。　　　　
貰ったギフティプレモはAmazonギフト券（チャージタイプ）に交換できます（電子マネー払いにて）　　　　　
　　　　
数分で出来るので是非ご利用下さい　　　　　

144 ：名刺は切らしておりまして：2019/03/29(金) 16:40:30.42 ID:SEXmiizE.net

>>135
ふつーにGPU使え

145 ：名刺は切らしておりまして：2019/03/29(金) 17:54:28.78 ID:a7psw1vM.net

>>1
Perlは鉄壁のセキュリティ
Perl最強伝説がまた証明された

146 ：名刺は切らしておりまして：2019/03/29(金) 18:08:33.58 ID:JMOOFpB9.net

>>142
分岐羅列のほうがキャッシュミスヒット減るだろな。
一連のアドレスにあるから。

147 ：名刺は切らしておりまして：2019/03/29(金) 19:00:54.69 ID:MT97NpcQ.net

>>146
分岐するブロック全体の予測成功確率は何しようが変わらない
CPU上の予測リソースの使い方が変わるだけ
多段になると各分岐命令でストールが起こるため予測失敗時のペナルティが大きくなる

148 ：名刺は切らしておりまして：2019/03/29(金) 19:10:01.06 ID:NTjdVycP.net

関数型言語のコンパイラ実装者だったら関数を多用した場合のパフォーマンスの出し方色々知ってそう

149 ：名刺は切らしておりまして：2019/03/29(金) 19:17:14.18 ID:SvRg/8KX.net

>>1
そもそも、一つの言語でアプリケーションソフトを開発することに無理がある

150 ：名刺は切らしておりまして：2019/03/29(金) 19:21:03.59 ID:MT97NpcQ.net

switch文で数値の連続性が高く、分岐先が多い場合コンパイラがテーブル化するのはそっちの方が速いからだよ

151 ：名刺は切らしておりまして：2019/03/29(金) 19:24:27.22 ID:SvRg/8KX.net

連係編集できない事こそ脆弱性を下げると思うけどね

152 ：名刺は切らしておりまして：2019/03/29(金) 19:46:53.30 ID:Eut6I2R7.net

■
つまり

１、オブジェクト指向を取り入れて、さらに
２、関数型　取り入れたら、

こういう順番になる。

153 ：名刺は切らしておりまして：2019/03/29(金) 19:53:56.04 ID:ZU/P86u3.net

>>58
マルチスレッドが出来たら世界のエースクラスだな。

154 ：名刺は切らしておりまして：2019/03/29(金) 20:08:15.48 ID:tc1163HP.net

人間もC言語やPHPな気風を孵化して止まないモンは誰にも制御不能
つーか、そんな外的インタラプトはすべて排除します
これは、飼い主の尾っぽを振って御仕舞な犬じゃなく

狼、ウルフ言語といいませうか？

155 ：名刺は切らしておりまして：2019/03/29(金) 20:08:56.45 ID:tc1163HP.net

犬リーマンで生を終えて満足できる「桁落ち」には使い熟せないと思う

156 ：名刺は切らしておりまして：2019/03/29(金) 20:09:38.29 ID:tc1163HP.net

>>153
全くお説、了解いたし候

157 ：名刺は切らしておりまして：2019/03/29(金) 20:10:35.26 ID:tc1163HP.net

Cを自由自在に転がしてこそヒカル「PHP」
文脈の基礎の無いバーカが弄るな

158 ：名刺は切らしておりまして：2019/03/29(金) 20:24:53.13 ID:xtrB4rfw.net

VB最強説？

159 ：名刺は切らしておりまして：2019/03/29(金) 20:55:25.06 ID:vfiafuyD.net

「脆弱性」を読めないばかりか
間違った読み方をわざわざスタッフに教えていた医者がいた
普通、医者ならほぼ100%読める単語なのだが
なぜだかアンタッチャブルらしくその後も絶賛出世中
その地区の方々は本当にご愁傷様です

160 ：名刺は切らしておりまして：2019/03/29(金) 23:08:26.21 ID:a2Lq4oms.net

>>144
ふつーにGPUを使っている例を教えてください！
GDCでもそういった内容の発表は過去に無かったと思います

161 ：名刺は切らしておりまして：2019/03/30(土) 06:47:30.69 ID:7/jVabj8.net

>>130
>バッファオーバーランは言語によってセキュリティが向上する部分だろ

Cコンパイラーがバッファーオーバーフロー・オーバーランのチェックをやってはいけない決まりはない（-fsanitize=undefinedか-fsanitize=signed-integer-overflow,-fsanitize=bounds,fsanitize=object-size,-fsanitize=vla-bound等の個別指定）
コンパイラがチェックをするのは当たり前すぎるが、そうした機能を知らない連中がセキュリティーが大変だと大騒ぎしている
言語の規格がサポートするしないに関わらず、アナライザーやチェッカーを使えば十分に排除できる（又は自前の共通マクロでチェック箇所をラップする）

言語指定のチェッカーはやり過ぎる嫌いがあるし、どうでも良いところに分岐を入れられるとシリアル化されて最適化が犠牲になる

Pythonのように完全に排除してしまうと、余計な命令が増えILP最適化が弱まるためパフォーマンスは悪化する
勝手にパフォーマンスを激減させるような命令を入れられるのは迷惑このうえない。記憶ではRustでもリリースモードでチェックをしないはずだし、チェックも完璧なはずはないので
油断してバグ（セキュリティかパフォーマンス）を入れる可能性はゼロではない

どの言語でもリグレッションテストを可能な限りやるだけなので、意図しない余計なアセンブリ言語がないぶんにおいてCのデバッグ時の簡易さは貴重だ

162 ：名刺は切らしておりまして：2019/03/30(土) 10:25:47.54 ID:kSzcfUlg.net

脳腫瘍の多いプログラミング言語は何？

163 ：名刺は切らしておりまして：2019/03/30(土) 12:53:05.21 ID:Ua8ELKCR.net

>>161
Rustでは常に境界チェックが行われるそうだ

Rust の Index bounds check の性能影響を調べてみた
http://gifnksm.hatenablog.jp/entry/2016/06/01/010152

Rust の配列 (Vec<T> や [T] など) では、インデックスアクセス時に境界チェック (index bounds check) が常に行われます。
常に行われる、というのはビルドの種類 (リリースビルド・デバッグビルド) に依存しないという意味です。
とにかく安全性を重視する Rust らしい仕様であると言えます。

他のプログラミング言語に目を向けて見ると、常にチェックが行われるシステムプログラミング言語というのも珍しい気がします。
すべてがプログラム作成者の責任になる C では当然何のチェックも行われませんし、
安全なシステムプログラミング言語という意味で Rust と立ち位置が近い D では、
デバッグビルドの場合のみ境界チェックが行われます (リリースビルドでは行われない)。

164 ：名刺は切らしておりまして：2019/03/30(土) 13:59:43.30 ID:olYQX1Jx.net

>>163
ということはSPECTOR系に狙われやすいんだな

165 ：名刺は切らしておりまして：2019/03/30(土) 14:02:28.31 ID:olYQX1Jx.net

境界チェックの正否に関わらずCPUがメモリ先読みしているお陰でパフォーマンス低下が押さえられていたんだな

166 ：名刺は切らしておりまして：2019/03/30(土) 17:38:18.07 ID:7/jVabj8.net

>>163
>常に行われる、というのはビルドの種類 (リリースビルド・デバッグビルド) に依存しないという意味です。

本当にRustが見境なく全てのアクセスで「境界」チェックをしているのなら、有難迷惑と考える方が多いだろう

リリースモード（ビルド）では最適化レベルがopt-level=3かopt-level=2のいずれかのはずで、本来であればそうしたチェックは最適化されないといけない
Rustコンパイラは、境界チェックをO(1)に「最適化」するはずなので、全てに境界チェックをするというのは誤りだろう

--emit asmで見たら最適化でコンパイラが不要と判断したチェックは消されているはずだ。時間があったら試して見てみると良い（LLVM自体の基本機能のはずだ）

>>164 の言うようなSpectreの例はともかく、言語が裏で勝手に色々とやるのはセキュリティーやパフォーマンスのデバッグをする際には邪魔でしかない

https: //people.csail.mit.edu/vlk/spectre11.pdf

Rust doesn't optimize bounds checks that Go 1.11 does
https:// github.com/rust-lang/rust/issues/51709

さらにループが複雑化すると、Rustコンパイラは最適化をしないと考えるべきで、ペナルティを払う必要が出てくる可能性もある

Why is my Rust implementation of InsertionSort slower than my C version?
https:// stackoverflow.com/questions/30965257/why-is-my-rust-implementation-of-insertionsort-slower-than-my-c-version

167 ：名刺は切らしておりまして：2019/03/30(土) 17:41:43.09 ID:7/jVabj8.net

>>166

境界チェックではないが、Rustのオーバーフロー系のチェックは大昔からの問題を蒸し返しているだけで、これを持って最終解決策と主張するのには無理がある

https://github.com/nikomatsakis/rfcs/blob/integer-overflow/text/0000-integer-overflow.md
Rust, at least, does not have to worry about memory safety violations, but it is still possible for overflow to lead to bugs. Moreover,
Rust's safety guarantees do not apply to unsafe code, which carries the same risks as C code when it comes to overflow. Unfortunately,
banning overflow outright is not feasible at this time. Detecting overflow statically is not practical, and detecting it dynamically can be costly.
Therefore, we have to steer a middle ground.

Rustコンパイラがデフォルトでチェックのために分岐命令を追加するのは、パフォーマンス的にはのぞましくなく、誤ったチェックを自動的に入れる可能性も排除できない

例えるならCコンパイラのコンパイルオプション（-fsanitize=undefined）をデフォルトで有効設定にしたビルドを使うだけで狂喜しているだけだ

168 ：名刺は切らしておりまして：2019/03/30(土) 17:44:08.05 ID:fCNT34Ml.net

そりゃCだろ、メモリ管理自分でやると簡単にオーバーフローやらかすｗ

数値計算系のFortoranとかは起こしようが無い

169 ：名刺は切らしておりまして：2019/03/30(土) 17:55:07.99 ID:7/jVabj8.net

>>166

Why is my Rust implementation of InsertionSort slower than my C version?
https://stackoverflow.com/questions/30965257/why-is-my-rust-implementation-of-insertionsort-slower-than-my-c-version

Test on C:

ARRAY SIZE: 100000
< counting_sort: 0.003602
< insertion_sort: 8.273647
< heap_sort: 0.017918

Test on Rust:

ARRAY SIZE: 100000
< counting_sort: PT0.039530982S
< insertion_sort: PT276.529915469S
< heap_sort: PT0.117946209S

170 ：名刺は切らしておりまして：2019/03/30(土) 18:09:10.41 ID:ekTIQA7Q.net

COBOLならまったく問題無い

171 ：名刺は切らしておりまして：2019/03/30(土) 18:13:43.26 ID:1ZJDti3O.net

懐かしいぞPTA

172 ：名刺は切らしておりまして：2019/03/30(土) 18:15:29.56 ID:7/jVabj8.net

一般論として、プログラミングにおいてコンパイラに最適化を任せるというのは日常的なことだ
可能な限りコンパイラの最適化を利用するのは良いし、自明で基本的な最適化はコンパイラに任せるべきだ

ただコンパイラやツールにも限界があり、本当にボトルネックがあるなら調査や分析、ボトルネック回避の修正が必要となる
言語の規格レベルでガチガチに制限されると自由度は下がるので、最適化できる箇所・範囲が狭められる

Cで単にチェックをしたいなら、-fstack-protector、-D_FORTIFY_SOURCE=2、-fsanitize=undefined等を指定すれば良い

173 ：名刺は切らしておりまして：2019/03/30(土) 18:33:04.57 ID:wQ70w0GT.net

>>45
Mfcのライブラリじゃね

174 ：名刺は切らしておりまして：2019/03/30(土) 18:41:03.39 ID:zJ6krigP.net

なんかオプションまで語り始める奴ｗｗｗ
こいつ前もこれ系のスレに出没してたやつと一緒だな

175 ：名刺は切らしておりまして：2019/03/30(土) 18:47:10.75 ID:olYQX1Jx.net

>>173
vcruntimeの方じゃね

176 ：名刺は切らしておりまして：2019/03/30(土) 18:54:31.58 ID:6eaeI+EF.net

意味不明なランキングだな、C言語の脆弱性が多いって
世の中結局C言語で書いてる、Pythonでもなんでも

177 ：名刺は切らしておりまして：2019/03/30(土) 19:07:56.04 ID:uVjJTF8w.net

この調査結果で
日本語プログラム言語ひまわりは脆弱性が全く存在しない
とはならんだろ

178 ：名刺は切らしておりまして：2019/03/30(土) 19:15:25.55 ID:f1nmq7Kz.net

ネットで使われる言語はハッキングの試みが多いから、より脆弱性が発見されやすいんでね？

179 ：名刺は切らしておりまして：2019/03/30(土) 19:16:22.69 ID:/Vc9f2Y/.net

>>13
プロトコル？
背伸び過ぎて転んだかな

180 ：名刺は切らしておりまして：2019/03/30(土) 19:51:30.28 ID:L/5SzHfg.net

>>13
プロトコルワロタ

181 ：名刺は切らしておりまして：2019/03/30(土) 21:44:25.30 ID:YmR0Pcm2.net

多分ここにコメした奴が使ってる言語と作ったソフトに脆弱性が多いと思うわｗ

182 ：名刺は切らしておりまして：2019/03/30(土) 23:49:21.11 ID:Ua8ELKCR.net

境界のチェックなんてJavaでやられていることで有名だったと思うのだが…
なんでこうなるかな

183 ：名刺は切らしておりまして：2019/03/31(日) 07:56:14.56 ID:w67BdJ75.net

そもそも、C言語は安全装置をつけないかわりに高速で何でもできるってのが利点だから当然でしょ？

安全装置がついてるけれど遅くてできることも限られる言語と同列にされても

コンピュータ制御で簡単に飛ばせるができることが限られるドローンと、
操縦が超難しいけれど宙返りでもなんでもできるラジコンヘリの違いみたいに

184 ：名刺は切らしておりまして：2019/03/31(日) 13:20:37.91 ID:nY9jENWl.net

>>183
それでもRustは高速さを売りにしているところが違うのだが
どちらかというとC/C++は配管むき出しの工場しか作れない言語

C/C++で住宅をつくると住人がけがをしてしまう

185 ：名刺は切らしておりまして：2019/03/31(日) 19:28:56.09 ID:JSI6xB3a.net

>>184

そのRustで高速さを追求したコードはCのSIMDライブラリーを使い、SIMDを使用していない（C言語で）コードしたプログラムのパフォーマンスに匹敵すると主張する連中がいるようだが
明らかにC++に慣れていないプログラマーがコードしたマルチスレッドプログラムに匹敵するパフォーマンスが出たと言われても説得力はない

C++で生ポインターを使うべきでない程度の至極当たり前のことを、できないという奇妙な前提で使いもしない生ポインターの危険性でC++を批判したり、優位点が一々チグハグな印象しかない

「R.E.S.F」「Rust Evangelism Strike Force」（Rust伝道攻撃部隊）に寄せられる最大の批判は、他の言語に対するありもしない批判にかまけて、
肝心の実装をするための時間を無駄にし、シンプルなC/C++ベースのコードのポートだけしかできていない点だ

LLVMはC++でコードされているわけで、危険なC++のコードに依存している段階で問題がある

186 ：名刺は切らしておりまして：2019/03/31(日) 19:55:20.92 ID:nKiA816B.net

>>170
同じ「C」で始まるけど、コボルは堅固性最高
しかし、C言語は素早く処理できなければ意味のない「通信」に適した人工言語
開放性と柔軟性があるがため、最初に決めるべきものはキッチリ決めとかないと、後はシラネーよ

コボルは、実に調教と馴致が簡単に出来る
C馬さんて、ジャジャ馬、調教がかなり難しい

187 ：名刺は切らしておりまして：2019/03/31(日) 23:01:22.34 ID:zbvy9Sjs.net

>>184
もしかして、テンプレートとかも知らない、かわいそうな子？