A.5.3 Pointer element access
The pointer element access operator does not check for out-of-bounds errors and the effects of accessing an out-of-bounds element are undefined
A.5.6 Pointer arithmetic
If a pointer arithmetic operation overflows the domain of the pointer type, the result is truncated in an implementation-defined fashion, but no exceptions are produced.
結局、バグチェックって何をやるの? (スコア:1)
実行時の動的なバグチェックに関しても、 境界チェックやヌルチェックは Java 程度だと思われます。 後は GC を導入することで dangling pointer を なくしている ぐらいでしょうか?
結局、 「C で掛かれたプログラムを Java で書き直すは大変でしょう? Cyclone でどう?」 というアプローチなのでしょうね。
Dynamic region のような スマートなメモリ管理機構を言語が サポートするのはありがたいですが、、、
コンタミは発見の母
Re:結局、バグチェックって何をやるの? (スコア:2)
Re:結局、バグチェックって何をやるの? (スコア:1)
CINT は C / C++ 言語の比較的忠実は インタプリタ処理系なので、 Java や Cyclone が 提供するような メモリ管理・保護の機能は 提供していないように 読めるのですが、、、
Java は、 C/C++ 言語の持つポテンシャルをあまり落とさずに memory access violation や dangling pointer や memory leak のバグを除去できる 丈夫なメモリ保護機構を導入しました。 セキュリティを求めて C / C++ のプログラムを Java に移植するのだとしたら、 このメモリ保護機構ゆえだと思います。
ネイティブコードを書く場合にも、 このメモリ保護機構と調和する ことが求められています (Java の ネイティブメソッドを書くための インターフェイスである JNI は、 「『ネイティブコードだからなんでもできる』のではなく、 『ネイティブコードでも Java の(メモリ保護の)作法を守ってよ!』」 と言っているように見える)。
一方 Java の対抗馬の C# は、 unsafe 文を導入することで メモリ保護機構を 一部を緩くしています。
例えば、 unsafe 構文の中では ポインタを使った配列のイテレート が可能ですが、 ポインタを使った場合には 配列の境界チェックが行われません。
C# の言語仕様書 [microsoft.com]には、 とあります。 勘弁してよ。
コンタミは発見の母
Re:結局、バグチェックって何をやるの? (スコア:2)
# あ、バグっぽいのめっけ。 < CINT
# 一応 FAQ 読んでからレポートしよう...