1

:: CreateProcess Windows呼び出しを介して外部からプログラムによって呼び出されている実行可能ファイル（fossil scm）があります。次に、stdoutとstderrがキャプチャされます。fossilのソースコードが利用できるので、そこから静的ライブラリを作成して直接呼び出しを発行したいと思います。現在、化石への通信はコマンドラインパラメータを介して行われ、通信はプロセスリターンコード、stdout、およびstderrを介して行われます。Fossilはprintfおよびfprintf呼び出しを介してstdout/errに書き込みます。

化石源の変更を最小限に抑えてこれを解決するための最良の方法は何ですか？stdout / errをインターセプトしてメモリバッファに送信するための信頼できるクロスプラットフォームの方法はありますか？

4

3 に答える 3

3

次のような手順で実行できます。

  • 化石のメイン関数の名前を別の名前に変更して、呼び出すことができるようにします
  • Fossil のメインを呼び出す前に、stdout/stderr を任意のファイルにリダイレクトします。

freopen("filename.out", "w", stdout);

  • 引数配列を形成し、fossil_main を呼び出し、ファイルから出力を読み取ります。
  • stdout ストリームの状態を復元する必要があります。そのためのクロスプラットフォーム メカニズムはありませんが、疑似ハンドル (Windows では CONOUT$ など) を使用できます。

ただし、これは壊れやすいことに注意してください。

  • main() の開始時にゼロで初期化されるはずのグローバル変数が存在する場合がありますが、これは main() の 2 回目の呼び出しには当てはまりません。
  • 化石は一部のプロセス/スレッドの状態 (ロケール、現在のディレクトリなど) を変更する可能性があり、確実に復元することはできません。これの特に悪いケースは、exit(n) の呼び出しです。
  • プロセスの終了時に通常のクリーンアップは行われません。開いたままのファイル ハンドル (共有せずに開いた場合、再度開くことができないようにするため)、メモリ リークなどが予想されます。
  • 明らかに、化石でのクラッシュ/ハングは処理が難しくなります (回避できる場合があります)。

通常はこれを行うことができますが、正当な理由 (パフォーマンスなど) があり、結果に直面して自分でバグを修正する準備ができている場合を除き、実行しないでください。

于 2010-12-25T18:48:52.397 に答える
3

あなたはしたいと言う

stdout/err をインターセプトしてメモリ バッファに送信する

これは、SCM プログラムに API を導入するのではなく、既存のコードを変更せずにテキスト出力の解析を続行したいことを示しています。もしそうなら、あなたの現在のアプローチを変える意味はないと思います。現在のアプローチでメモリ バッファと静的リンクを使用すると、正確には何が得られるのでしょうか?

于 2010-12-25T18:44:12.220 に答える
0

fossilを共有ライブラリに変換し、カスタムプログラムからそれを使用します。

于 2010-12-25T18:35:00.970 に答える