0

うまく動作しない mbstowcs() があります。

mbstowcs(pParams->strDstFile, parParams->DstFile, sizeof(parParams->DstFile));

デバッグ時の引数の値は次のとおりです。

pParams->strDstFile = 0x0018e70c
parParams->DstFile = 121 long null terminated string.
sizeof(parParams->DstFile) = 1024

引数のタイプは次のとおりです。

TCHAR strDstFile[2048]; 
char DstFile[1024];

mbstowcs( wchar_t *pwcs, const char *s, size_t n) への単一のステップの後:

wchar_t  *pwcs = 0x0018ef0c

これは、送信されたものとは異なる値です。これにより、上記の呼び出しが誤動作します。

別の関数呼び出しで ps 、これとほぼ同じで、最初の引数 (pwcs) が異なるだけで、問題はありません。

アプリを連続して実行すると、まったく同じアドレス値で同じ結果が得られます。

別の投稿を見ていると、ぶら下がっているポインター/バッファー オーバーフローのように見えますが、メモリ ブレークポイントで追跡することはできません。

多分スタックの破損だと思いますか？

皆さんありがとう。

4

1 に答える 1

0

TCHAR およびさまざまな TCHAR マクロが展開される方法には、いくつかの異なる影響があるようです_UNICODE vs UNICODEおよび _UNICODE vs UNICODE に関するこの投稿を参照してください。

max size 引数を使用する場合mbstowcs()は、ソース バッファのサイズではなく、デスティネーション バッファのサイズを文字数で指定する必要があります。これにより、バッファ オーバーランを防ぐことができます。mbstowcs の説明も参照してください。文字数が最大になるとゼロ終了しない ことに注意してください。これmbstowcs()は、ほとんどの文字操作関数と同様の動作です。

はワイド文字列用であるためmbstowcs()、TCHAR ではなくワイド文字列を使用する必要があります。

あなたの問題はスタックの上書きが原因のようです。同じテスト データを使用していますか、それとも異なるデータを使用して異なる結果を得ていますか?

Microsoft が Visual Studio 用に導入したさまざまな TCHAR および _T() 拡張機能は、Windows 95/98 などの非 UNICODE バージョンの Windows と、Windows XP などの Windows の UNICODE バージョンの間でアプリケーションを簡単に移植できるように設計されています。マルチバイト文字列機能は、Windows XP や Windows などの 32 ビット Windows バージョンの一部である UNICODE のコア Windows API サポートがあまりないため、Windows 95/98 のタイ語や簡体字中国語などの言語のサポートを提供するようにも設計されました。 CE。

Windows XP 以降の UNICODE の世界では、ソースとコンパイラの設定が少し複雑になるだけなので、TCHAR 拡張機能を使用する価値はほとんどないようです。

UNICODE ではなくマルチバイト文字列を使用している理由がわかりません。Windows 98 と Windows XP の両方を対象とする古いアプリケーションがあり、ユーザー インターフェイスで何らかの変換を行いますが、すべてがワイド文字の UNICODE 文字列として内部的に保存されます。マルチバイト文字列の最初のサポートをアプリケーションに導入したのは、当時は必要に思えたからでしたが、当時は良いアイデアのように思えたものの、複雑さをもたらしたので、やらなければよかったのにと思いました。似たようなことをしているのかもしれません。

于 2012-08-11T15:07:23.817 に答える