問題タブ [memory-safety]

私は CentOS 6.4 32 ビットを使用しており、プログラムでバッファ オーバーフローを引き起こそうとしています。GDB内では機能します。出力は次のとおりです。

ただし、プログラムスタックを単独で実行すると、セグメント障害が発生します。これはなぜでしょうか？

関数の属性@safe、pureおよびnothrow親関数のコンパイル時と実行時のパフォーマンスに関して、文字列を構築するための推奨される方法は何ですか?

たとえば、どちらを使用する必要がありますか

また

formatバージョンの方が見やすいと思いますが、他の点では優れていますか?

フォーマット文字列とその引数を CTFE する必要があるため、コンパイル時にわずかなパフォーマンス ヒットが発生する可能性があります。

データを A TClientDataSet から B にコピーする関数を作成しました。

本番環境では、コードは次のように TClientDataSet を動的に埋めます。

それは言った：

• そうしても安全ですか？(安全とは、どのような例外が予想され、どのように対処すればよいのでしょうか?)
• 「.Data」のメモリを解放するにはどうすればよいですか?

Haskell の quickcheck ライブラリを使用して、いくつかの C コードをテストしたいと考えています。最も簡単な方法 foreign importは、得られた haskell 関数の上にプロパティを作成して書き込むことです。これに関する問題は、C コードがセグメンテーション違反を引き起こしたり、メモリを破損したりした場合、テストが出力なしでクラッシュするか、まったく予測できないことを行うことです。

2 番目の方法は、C ビット上に単純な実行可能ラッパーを作成し、テスト プロセスの外で を介して実行することSystem.Processです。言うまでもなく、これを行うには多くのスキャフォールディングと値のシリアル化が必要ですが、一方でセグメンテーション違反を処理できます。

foreign import外部プロセスを実行するのと同じくらい安全に戦略を立てる方法はありますか?

ポインターを備えた言語では、コンパイラーがコンパイル時にすべてのポインターが正しく使用されているかどうか、および/または有効である (生きているオブジェクトを参照する) かどうかをさまざまな理由で完全に判断することはできないことをどこかで読んだことがあります。本質的に停止問題の解決を構成します。この場合、この関連する質問で述べられていることと同様に、コンパイル時のプログラムの実行時の動作を推測できるため、直感的には驚くことではありません。

ただし、私が知る限り、Rust 言語では、ポインターのチェックをコンパイル時に完全に行う必要があります (ポインターに関連する未定義の動作はなく、少なくとも「安全な」ポインターはなく、「無効なポインター」または「null ポインター」のランタイムはありません)。いずれかの例外)。

Rust コンパイラが停止問題を解決しないと仮定すると、誤りはどこにあるのでしょうか?

• ポインターのチェックがコンパイル時に完全に行われるわけではなく、Rust のスマート ポインターは、たとえば C の生のポインターと比較して、実行時のオーバーヘッドをまだ導入しているのですか?
• それとも、Rust コンパイラが完全に正しい決定を下すことができず、おそらくライフタイム アノテーションの 1 つ (<'lifetime_ident>構文を持つもの) を使用して Just Trust The Programmer™ を使用する必要がある可能性はありますか? この場合、これはポインタ/メモリの安全性が 100% ではなく、プログラマが正しいコードを書くことに依拠しているということですか?
• もう 1 つの可能性は、Rust ポインターが非「ユニバーサル」または何らかの意味で制限されているため、コンパイラーはコンパイル時にそれらのプロパティを完全に推測できますが、C の生のポインターや C++ のスマートポインターほど有用ではありません。
• あるいは、それはまったく別のもので、1 つまたは複数の を誤解しているのかもしれません
  { "pointer", "safety", "guaranteed", "compile-time" }。