アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
ウイルス感染環境作んなボケェ! (スコア:-1, 荒らし)
メモリ破壊コード (スコア:1, 興味深い)
Re: (スコア:2, 参考になる)
別に何を再現する必要も無いのでは?
不定というのは、結果がどうなっても構わないという意味です。
暴走、例外はおろか、鼻から悪魔が飛び出しても言語規約上許されますし、
そんな分かりやすいリアクションではなく、一見正しく動作しているフリをしても構いません。
数多くのプログラマを苦しめてきた、Cの暗黒面の筆頭といって良い仕様です。
Re: (スコア:1, おもしろおかしい)
指定された壊れたメモリ領域を律儀に読み込んでとんでもない動作を実行し続けるだけで。
壊れていようがなんだろうがお構い無しに実行するのがCという言語の仕様。
まあコードからだけでは動作を予測し切る事は一般にできないもんだけど。
Re: (スコア:2, 参考になる)
なんかprintfをつけたら症状が出なくなったからデバッグ完了、と同じ類のvoodoo臭がぷんぷん漂ってきますよ。
Cの規格では確保したバッファの範囲外を読んだり書いたりアドレスを生成するだけで不定になります。
確保したバッファ+1のアドレス生成だけは認められていますが。
Re: (スコア:1, 興味深い)
アドレスを生成した時点で不定だったっけ?
void* pv = (void*)(0xDEADBEEF);
このコードが存在するだけで不定って意味になるけど、pvを使ってアクセスしなければ不定にはならないと思うよ。
Re: (スコア:2, 興味深い)
はポインタの指す先を読み書きしなければ大丈夫です。
整数はどんなポインタにも変換可能と規格で決まっています。
undefined なのは
char buf[1]; や char *buf = malloc ( 1 );
があったときに、(buf-2) や (buf+2) を含む式を評価した場合です。
例えば オーバーフローがあると例外を発生させるような種類の CPU で、
buf がメモリ空間の端っこ付近に割り当てられていたりすると
ひどい目にあうかもしれません。
一方 (buf-1) や (buf+1) は評価できることになってます。
一個までなら配列の範囲外を指すポインタを生成しても
オーバーフローしないと規格で決められています。
先の例で言うと、 buf はメモリ空間の端っこに配置されません。
必ず一要素分以上隙間があります。
Re:メモリ破壊コード (スコア:0)
> buf がメモリ空間の端っこ付近に割り当てられていたりすると
> ひどい目にあうかもしれません。
オーバーフロー検出機構のないCPUで一見正常に実行を続けられるせいで
任意コード実行とかされちゃうほうが「ひどい目」だと思う。
他の高級言語みたいにオーバーフロー検査を言語仕様で強制してほしいくらいなんだが
Re: (スコア:0)
メモリにアクセスする度にソフトウェア的に監査するといった、多大なコストを要求してしまうのです。
現在のPCでは、最低レベルの環境ですら大したコストでは無くなってきましたが、
20年前、30年前の手頃なパソコンやワークステーション、あるいは現在においても組込み分野などでは
とても無視できるものではなく、だからこそそういう無駄あるいは贅沢を排したC言語がもてはやされたのです。
もっともCの規格上そういう機能を持ってはいけないという
Re: (スコア:0)
> とても無視できるものではなく、
これから言語仕様に追加してほしいという話ですから昔のことは関係ありませんし、組み込みで問題ならフリースタンディング環境は除いてもかまいません。もはやホスト環境では弊害のほうが大きいと思います。
> もっともCの規格上そういう機能を持ってはいけないという決まりもないので、
> そういう安全装置を備えた処理系も探せばあるかもしれません。
というかあります [srad.jp]。