-1

この質問のコードスニペットの欠如とその曖昧さについて、今しばらくお待ちください。しかし、私はまったく無知であり、バグの場所についての手がかりがなく、アプリケーション全体を貼り付けることはできません。

C通常のAPI（など）を介してファイルを開き、fopen一定時間データを書き込み（最初にバッファをzlibに渡してデフレートしますが、これは適切ではないと思います）、最後にクロスプラットフォームアプリケーションがあります。フラッシュして閉じます。

これは、UACがオンになっているWindows OS x64での64ビットビルドを除いて、すべてのプラットフォームで完全に正常に機能します。stdout基本的に、その正確な設定では、ファイルバッファは、ファイルを開いてからフラッシュするまでの間に送信したものと文字通りインターレースされているように見えます。まるでstdout、他のファイルの同じバッファを使用する書き込みがあるかのようです。

VirtualStore私が書いているように、これはファイルシステムの仮想化（メカニズム）に関連してはならないことに注意することが重要です%USERPROFILE%\Saved Games\。この問題は確かにUACに関連しています。これをオフにすると、問題は発生しません。でも問題ありませんwine64。

どんなポインタも価値があります。コンパイラはg++4.7.0（Linuxからのクロスコンパイル）です。

4

1 に答える 1

0

この問題の回避策を見つけました。

最初のブロッカーは、アプリケーションをでコンパイルしたため、アプリケーションを-mwindows親プロセスコンソールに接続できなかったことです。しかし、に切り替えること-mconsoleはそれを修正するだけではありませんでした。この変更があっても、私が送信したものはすべてstdoutコンソールに送信されていませんでした。それは大したことではなかったので、私は質問でこの問題を述べませんでした、アプリケーションはそれに別の種類のコンソールを持っています。

問題全体は、のバグ（または文書化されていない動作の変更）が原因であると確信していますmsvcrt。基本的に、私のアプリケーションが起動したとき、stdoutは有効なポインターですが、実際には親コンソールに接続されていません。出力を確認するには、を実行する必要がfreopen( "CON", "wt", stdout );あります。さらに、fileno(stdout) UACがなく1ても正しく戻りますが、UACがオンstdoutの場合でも有効なポインターですが、fileno(stdout)戻り値を呼び出すための呼び出し-1です。stdout2番目のケースで実際にどこを指しているのか疑問に思います。

でコンパイルすると-mwindows、fileno(stdout)3が返されることに注意してください。POSIX標準でファイル記述子番号を1にする必要があるかどうかはわかりませんがstdout、少なくとも3を選択するのは珍しいことです。

于 2012-10-01T01:52:20.617 に答える