Microsoft、C言語を拡張した「Checked C」をオープンソース化 57
ストーリー by headless
後回しにして結局有効にしないパターン 部門より
後回しにして結局有効にしないパターン 部門より
C言語を拡張して安全性を高めた「Checked C」をMicrosoftがオープンソース化した(InfoWorldの記事、
Softpediaの記事、
Microsoft Research — Checked C)。
Checked CはC言語にポインタの境界チェック機能を追加したことが名前の由来となっている。チェックに対応する新しい種類の配列型やポインタ型が追加されており、スコープを指定してチェックを強制することもできる。チェック機能を使用しない既存のCプログラムもそのまま使用できるため、後で徐々にチェックを有効にしていくことも可能だという。
現在、Checked CはLLVM/clangをフォークして実装されており、いずれはアップストリームへのマージも計画しているという。ソースコードはGitHubのChecked C clangリポジトリおよびChecked C LLVMリポジトリから入手可能だ。ライセンスはイリノイ大学/NCSAオープンソースライセンスとなっている。
Checked CはC言語にポインタの境界チェック機能を追加したことが名前の由来となっている。チェックに対応する新しい種類の配列型やポインタ型が追加されており、スコープを指定してチェックを強制することもできる。チェック機能を使用しない既存のCプログラムもそのまま使用できるため、後で徐々にチェックを有効にしていくことも可能だという。
現在、Checked CはLLVM/clangをフォークして実装されており、いずれはアップストリームへのマージも計画しているという。ソースコードはGitHubのChecked C clangリポジトリおよびChecked C LLVMリポジトリから入手可能だ。ライセンスはイリノイ大学/NCSAオープンソースライセンスとなっている。
最初の目標 (スコア:2)
Re: (スコア:0)
で、配布されたコンパイラには「自分のソースをコンパイルすると、ソースツリーのどこに書かれていない、バックドア作成機能を自分自身のオブジェクトファイルに埋め込む」機能が実装済みと。
これは古き悪しきネタ。
これでWin32アプリとかビルドできるの? (スコア:0)
すでに境界チェックを行っているマネージコードでは意味がないし、
Win32アプリをビルドできない程度のオモチャだったらFail-Safe C [developers.srad.jp]とかと比べて何が新しいのかもよくわからない。MSらしく独自拡張で実現しているあたり?
Re: (スコア:0)
InfoWorld の記事を今ちらっと読んだけど、確かに新しくわざわざ作った経緯がよくわからない。
しかしMSとしてもまったく意味が無い物を、流石にわざわざ作ったり、ましてそれを発表したりもしないと思うので、
（良くも悪くも意味が無いので）
もうちょっと・・・特徴より経緯を掘り下げないとわからない。
個人的にはC++がベースになってくれると嬉しかったが、そういう事じゃないと思うのでそこは不問。
Re:これでWin32アプリとかビルドできるの? (スコア:1)
こっちは C とは別の C互換の言語を作って、開発時に開発者が明示的な利用範囲を書いて、明示的なメモリチェックをやるってコンセプトだから、再発明どころか似たようなものですらない。
Re: (スコア:0)
まあ、最大手が車輪の再発明をしたらあかん、ってな決まりがあるわけでもないですし。
言語が広く使われるようになるかどうかも、その言語自体が優れているかのほかに、
背後に誰が付いているかとか、どこでどう使われようとしているかというような意味を含めての将来性とか、
ライブラリがどのぐらい出揃うかの実用性とか、そんなことにも強く依存しますし。
Re: (スコア:0)
大手っていうか余裕があるところは使わない前提で作るだけ作ってそこから得た知見をほかで活用することもあるからな。あとは社員教育？
Re: (スコア:0)
普及させるなら、最終的に.net frameworkでも使えるようにするのではないかい。
Re: (スコア:0)
.Netってクラスライブラリでないの？オブジェクト指向言語でないC言語からは使い辛いんでないの？
C++ではないBetter C (スコア:0)
俺が知らないだけだろうけど、Better Cといえば、C++だったり、さらにそれから派生したJavaはあるけど、オブジェクト指向に走らずに、Cと同じコンセプトのBetter Cって提案されているんだろうか。
Modula-2とか？
今回のChecked CはCと互換性があるみたいだけど、互換性のないBetter Cも見てみたかったり。
Re: (スコア:0)
RustとかGoとかSwiftとか。MSは新言語ではなくCの拡張で行くつもりなのかもしれない
Re: (スコア:0)
MFCとかのフレームワーク見ると継承とかポリモーフィズムとかを意識して
コードいじらないといけないOOP臭ぷんぷんなんだけど、
最近のC++1xとかboostとかはOOPの機能は使われているんだけどOOP臭がしない。
C++はOOP以外の何かに進化しつつある。
Re:C++ではないBetter C (スコア:1)
オブジェクト指向は並列処理に向かないからなぁ、C++のクラスは組み込み型定義構文というのが近い
スレッド単位の並列ならスレッドと対応したアクターモデル、データ単位の並列ならSoA(配列の構造体)
全てがオブジェクトなオブジェクト指向よりも、アクター（処理の主体）とデータ（処理の対象）を明確に分離した方が効率がいい。
Re: (スコア:0)
オブジェクトを排他制御の単位とすべきかメソッド単位にすべきか明示的にすべきかについては昔から議論されていたが、どうでもいいというのが結論だった気がする
とくにimmutableなデータ構造の重要性が認識されている今日では
Re: (スコア:0)
STLが世に出てから一体何年経っていると…
C++はずっと昔から先に行っていたよ。
Re: (スコア:0)
はっきり言ってC++はOOPを目的とはしているとは言えない。
割合で言えばOOPのための言語仕様は一部に過ぎないし、
OOP論者からはOOP言語としては否定されることも多かった。
Re: (スコア:0)
開発者は、利用したい部分を利用すればよくて、言語側から強制されるものがほとんどない。
OOPに限らないけど、純粋さを綺麗とする考え方とは真逆
このあたりの思想って C# もガッチリ受け継いでるよな。
Re: (スコア:0)
Modula-2を嫌がって（？）C言語風のスパイスをまぶしたModula-3を作った人たちがいるくらいだから、今更Modula-2は受けないでしょう
Pascal系の言語のクラシックな処理系はarrayの境界チェックがデフォルトでオンになってたりするけど、モダンな（？）処理系ではオーバヘッドを嫌ってそういうチェックはしない流儀
組み込みC言語 (スコア:0)
組み込みシステムだと需要はあるのでは。
オブジェクト指向があるとその処理が複雑になるが、C言語だと記述した流れがそのまま機械語になる。
組み込みC言語の仕事はまだまだ減らないだろう。
だけどバグやらハッキングやらを避けたいのでセキュリティだけ改善してみた、って考えれば合理的。
そうだとすると、Microsoftがなんで作ったのかという問いが出てくる。
ユビキタスな仕事に手を出そうとしているとか。
Re:組み込みC言語 (スコア:1)
MSといっても、Microsoft Research ですからね。本体の営業政策とは独立に、いろいろ手を出しているのだとおもいます。
Re: (スコア:0)
IoT Coreっちゅうものがありましてね。
Re: (スコア:0)
組込み屋の自分は、静的にコンパイルできてC++よりマシなモダンな構文のOO言語が欲しい。
組込みもクラス指向のOO使いたいんだよ。特に画面があると。
だけどRAMが少ない環境なのでインスタンスをホイホイ使い捨てる言語は苦しい。
RubyやPythonが使えたら素晴らしいけど、4kRAMのマイコンではさすがに使えない。
リアルタイムなのでGCが走るのも困る。
RAMの制約あると…取捨選択が必要 (スコア:0)
スパコン←「2位じゃダメなんですか？」
マイコン←「Cじゃダメなんですか？」
Re: (スコア:0)
スパコン←「2位じゃダメなんですか？」
話になりません
マイコン←「Cじゃダメなんですか？」
駄目じゃないけど...
きづけばCフリー (スコア:0)
サーバサイドではrubyかnode.jsかscalaか
クライアントアプリでもswiftやJavascriptオンリー。AndroidアプリならまだJavaだっけ？
気づけば人類はもはや素のC言語を必要としなくなってるんだなあと思った
もう少し、Objective-Cの資産が残ってる程度かな
このChecked Cはどこで使うんだろうか？
工場の古くて小さなコンピュータの延命とか？
Re:きづけばCフリー (スコア:1)
速度を出すためだと思いますがnode.jsだとパッケージによってはCのモジュール使っているやつがありますね。
他人のマシンに環境構築しようとしたらパッケージがビルドできなくて面倒な目にあった。
Re:きづけばCフリー (スコア:1)
組み込みソフトを忘れないで～
何だかんだでかゆいところに手が届くC言語は便利なのですよ。
Re:きづけばCフリー (スコア:1)
このストーリーでMSのリンク先を読んでるやつは俺以外に一人しかいないのかよ
> The extension is designed to be used for existing system software written in C.
とか
> Most system software is written in C or C++, which is based on C. System software includes operating systems, browsers, databases, and programming language interpreters. System software is the “infrastructure” software that the world runs on.
とか
> The Checked C extension will let programmers add checking to their programs to detect these kinds of errors when a program runs or while it is being written. Existing system software can be modified incrementally in a backwards-compatible fashion to have this checking.
Re: (スコア:0)
よし、その調子で翻訳もしてくれ
Re: (スコア:0)
英語くらい読めよ バカ
Windows10で使うのでしょう (スコア:1)
夏のWindows 10 Anniversary UpdateでWindows Subsystem fo LinuxというLinux向けのプログラムをそのままWindows10に提供する予定があります。
多くのプログラムはCで書かれているので、Windows向けにビルドするついでに、より安全にすることができるはずです。
Re: (スコア:0)
> Windows向けにビルドするついでに
Windows Subsystem for LinuxはUbuntus向けにビルドしたELF64バイナリをそのまま動かす思想だから的を外してる感
Re: (スコア:0)
アプリはそうでもVMとかOSとかは別なんじゃないの？
まあAndroidでもNDKならCもあるからフリーとは言い切れないけど。
Re: (スコア:0)
デバイスドライバや共有ライブラリなど、OSに近い部分叩く所では、まだCも出番ありそう。
Re: (スコア:0)
井の中の蛙、人類を語る
すっかり囲い込まれたその環境は何で作られてるんだろうね？
Re: (スコア:0)
組み込みでないのに素のCばかりでプログラム書いていますが何か？
C言語は言語仕様で安全性を担保してくれていないこともさることながら、現代のプログラミング言語の持つライブラリとして貧弱。また、C言語で書くプロジェクトは車輪の再発明的なライブラリの作成を期待されることも多いのはいかがなものか
Re: (スコア:0)
サーバサイドではrubyかnode.jsかscalaか
クライアントアプリでもswiftやJavascriptオンリー。AndroidアプリならまだJavaだっけ？
気づけば人類はもはや素のC言語を必要としなくなってるんだなあと思った
rubyやその他は人類以外の神か何かが作ってるという認識かな?
Re:きづけばCフリー (スコア:1)
Re: (スコア:0)
そのSwiftやJSのランタイム自体ってネイティブコードで作られてるんじゃないの？
Re: (スコア:0)
そこらへんの言語で書かれた動作速度に不満が無ければそれでいいんじゃない？
Re: (スコア:0)
皆さんはAndroidアプリをどんな言語で作ってるんですか。
XamarinとかApache cordovaしか思いつかないですがそんなわけないでしょうし。
Re: (スコア:0)
Android StudioでサポートされているKotlinとかじゃね
そんなのより (スコア:0)
AddressSanitizerをWindowsでも動くようにしてくれよ
互換性のないC言語モドキを書く奴がどれだけ居るんだよ
CのVMでも作ればいい (スコア:0)
従来方式で書いた場合は保護できないし
新方式だと互換性が無いしで中途半端な印象
いっそC言語を適当な仮想マシンのコードにコンパイルするほうがマシなんじゃ
Re: (スコア:0)
いっそC言語を適当な仮想マシンのコードにコンパイルするほうがマシなんじゃ
どういう理屈かサッパリわからん。
Re: (スコア:0)
valgrind 「呼んだ?」
https://ja.wikipedia.org/wiki/Valgrind [wikipedia.org]
Re: (スコア:0)
標準関数を考えなしで使ってオーバーフロー引き起こすのが主だろうから
ユーザーコードにリターンする前にライブラリ側が判断してabort返す必要があるて事はC標準関数を低コストに呼べない・呼んだら黙阿弥、互換性もくそもない
スタックに作る配列チェックは自前コード内ならメタマクロで十分対応できるし
ヒープは壊れても平気ではないけどマズ攻撃には使えんし
このC言語もどきの生きる道はどこにあるんだろうね
Rustじゃん (スコア:0)
ポインタや配列の安全な取り扱い、
スコープに基づくポインタの管理
どちらもRustがやってる
一応、Cのほうがずっと前から普及してて、書き換えるコストは低い、という点を指摘してる記事もあるけど、
今からChecked Cが普及するのか
Rustに書き換えるよりは楽だろうけど
結局、古いC言語のまま使われるような気がする
Re: (スコア:0)
既存のコードもそのまま動くわけだから、バグが出たときに関連しそうな所だけチェック構文追加して、動かしてみて、原因わかれば、バグ治すのと、チェック用の構文は削除してしまって、元のコンパイラで動かしてもいいわけですよ。
不毛な拡張とか良いんで標準に準拠して (スコア:0)
MicrosoftからC99開発者へ: ISO C++を使え
https://www.infoq.com/jp/news/2012/05/vs_c99_support