Serviceを読んで理解し、同意したものとみなします。スタック・オーバーフローはプログラマーとプログラミングに熱心な人のためのQ&Aサイトです。指定してコンパイル実行すると3.1415930.000000のように%lf指定した方が0.000000になってしまいます。test.c)でコンパイルした場合3.1415933.141593のように期待する結果が得られます。使用はC99では適合のはずなのでおかしな結果です。(バグフィックスされるまで)困るので回避方法を探しています。C99オプションなしでコンパイルした場合問題ないので、なんらかの方法で回避できるのではないかと思っています。test.cであってもWandboxでは正しく動作しました。TDM-GCC固有の問題かもしれません。12:34コメントでの例のように別のオプションを追加指定するか通常のシステムヘッダの利用に先立ちなんらかのマクロを指定する(あるいは-Dオプションでマクロ指定)。includeヘッダなどを直接修正するというのは最終手段。gcc(コンパイラ関連)自体のソースは修正しない。C99準拠であれば使えるはずですが、GCCのC99準拠状況リストを見ると、%lfへの対応はライブラリの仕事であってコンパイラがすべきことは無い、と言っています。今手元にTDM-GCC環境が無いので試せないのですが、もしかしたらライブラリのバージョンも関係してくるかもしれないです。試してみたんですが%lfは機能しているようでした。この場合doubleのサイズも同じだと思われるのでおそらく関係ないかと思うんですが、gccからのmsvcライブラリの呼び出し時に未対応だとgccがみなしているというのはあるかもしれません。stdioの2種類のstdioが存在します。__mingw_printf()と__msvcrt_printf()の名前でアクセスできます。6.0のものですので、C99やC11といった仕様とは無縁です。Functionsにprintf()のドキュメントがありましたが、%zuという指定も存在しません。stdioは<stdio.h>の次の記述により__USE_MINGW_ANSI_STDIOの値により動作が切り替わります。__VALIST);#endifここで__USE_MINGW_ANSI_STDIOは<_mingw.h>で設定されています。endif#endifコンパイルオプション-std=c99や-ansiを付けると__STRICT_ANSI__が定義されることに連動して__USE_MINGW_ANSI_STDIOも定義されます。stdioとが切り替わります。原理がわかれば明快です。-std=gnu99を指定する(-std=c99や-ansiを指定しない)-D__USE_MINGW_ANSI_STDIO=0を指定するprintf()ではなく__msvcrt_printf()を使用するぐらいでしょうか。stdioが%lfを正しく扱えない原因TDM-GCCのソースコードmingwrt-3.21-mingw32-src.tar.xzを確認しました。printf()は最終的にmingwex/stdio/pformat.cで定義されている__pformat()に辿り着きます。doubleと見なすようになっています。80bitとしていました。doubleをprintf()する際に%lfを使用していました。64bitと変更しました。doubleを表していてもdoubleを表していてもどの道64bitであり影響がなくprintf()の使い方としては曖昧になってしまいました。C++に合わせて64bitとすべきところ)。これは仕様バグとしか言いようがありません。doubleとみなしてしまっています。double)v);等、明示的なキャストを行い正しく引数を与える必要があります。別の根本的な解決方法としてはgccのコンパイルオプション-mlong-double-64を使うことです。これを実現するにはprintf()を含むランタイムすべてをビルドし直す必要があります。いうかgccからビルドし直す方が早いでしょうか。__USE_MINGW_ANSI_STDIOマクロについて<_mingw.h>には次のコメントがあります。codeとありますから、指定しても構わないと思います。stdioとの切り替え選択という内部実装に強く依存した行為ですから、指定するには細心の注意を払うべきですし、注意して行うのであればためらう必要はないかと。使うとどうなるのでしょうか?これに関しては本回答及びコードをよく確認してください。__USE_MINGW_ANSI_STDIOを不成立させたいのですから、いずれを#defineしても期待する結果は得られません。使用できなくなります。さん、ここで確認しましたがそのような条件は挙げられていませんでした。質問文を訂正してください。0:13もちろんそう(%zuについては書いていなかった(書いた時には気づいてなかった))なんですが、-std=c99のオプションを指定する(したい)理由は要するにC99での(コーディングとそのコンパイル(コンパイラによるチェック)もろもろの)実行動作だというのは理解していただけますよね。返値についてでもコメントしましたが、規格・仕様と実装は別問題です。MSVCRTはMS-DOS時代から30年以上の歴史・互換性を維持していますから、仕様通りには動作しない部分もあります。返値についてでもコメントしましたが、規格・仕様と実装は別問題です。6.0はC99準拠を謳っていないはずです。TDM-GCCはC99に準拠していません。C99を使用したいのであれば、C99に準拠した環境を選択すべきです。doubleへの指定だと解釈される)のようです。double)v);とすると期待する値が表示されました。少なくとも現状は機能しないようです。-std=gnu99を使用するのが簡易な解決のようです。)標準規格指定がされた時に参照ヘッダが切り替わることが動作が異なる理由らしいですが、そこら辺の切り替えをユーザーから問題を起こすことなしにうまく切り替えることができたらいいんですが、多分色々絡み合ってて難しいんでしょうね。(コメント参照)mingw.orgにあるwiki上のC99についてのページ。ここにMSVCRTとMinGWのC99についての歴‌​史が短く書いてあります。無視されるので無駄だ。無視されるので無駄だ。14:191MinGWのメーリスに、__USE_MINGW_ANSI_STDIOは普通のユーザーが設定するべきではないと書かれたメールがありました。14:441mingw.orgにあるwikiにC99についてのページがありました。ここにMSVCRTとMinGWのC99についての歴史が短く書いてあります。件のコメントを表示0-std=c99指定の時は、"%Lf"と同じ扱いをされてしまっているのかな?printf()は可変長引数でfloatはdoubleに拡張されるため、昔は"%lf"は間違いでした。C99で"%lf"が許されるようになったとはいえ、敢えて"%lf"にしなくても良いのではないでしょうか。|回答スタック・オーバーフローに参加してくれて、ありがとうございます!質問の回答を共有してください。回答を説明し、自分の検討結果も共有してください。意見を述べること(意見を述べるなら、参照リソース、自分の経験で意見をサポートしてください)さらにサポートが必要な場合このヘルプを参考してください。“回答を投稿”をクリックすることで利用規約、プライバシーポリシー、及びクッキーポリシーに同意したものとみなされます。タグが付いた他の質問を参照するか、自分で質問をする。bufferについて5Cのprintfでの$(ドルマーク)の意味0ファイル名が.#で始まるファイルに対して、cmakeで作製されたmakefileをmakeするとエラーを吐く1MinGWのg++にfilesystemヘッダが存在しない2WindowsでTCPクライアントをC言語で書こうとしたところ、コンパイルエラーが出ます。質問のフィードこのRSSフィードを購読するには、このURLをコピーしてRSSリーダーに貼り付けてください。