問題タブ [gcc-warning]

これは私の警告です。

どうすれば削除できますか。

私はLinuxとgccコンパイラを使用しています。

symbol.c：関数'symbol_FPrint'内：

symbol.cで

そして、SYMBOLは次のように定義されます。

'％ld'を'％zu'に置き換えると、次の警告が表示されます。

注：ここから2010年3月26日に編集され、上記の問題と類似しているため、以下の問題が追加されました。

私は次のステートメントを持っています：

64ビットアーキテクチャでのコンパイル中に発生する警告は次のとおりです。

パラメータの定義は次のとおりです。

32ビットおよび64ビットアーキテクチャで警告なしにコンパイルできるように、これを取り除くにはどうすればよいですか？

その解決策は何でしょうか？

対応するコードは次のとおりです。

SYMBOLは次のように定義されます。

どんな努力も大歓迎です。

PRECEDENCEは次のように変更されました。

symbol_Orderingの追加情報は次のとおりです。

{return symbol_ORDERING ++; }

config.hライブラリとそのライブラリ上に構築されたソフトウェアの両方にautotools（ファイルを含む）を使用すると、コンパイラは一部のマクロ（PACKAGE_NAME、PACKAGE_TARNAMEなど）の再定義について文句を言います。

どうすればこれを防ぐことができますか？

このconfig.hファイルは、その設定をそれを使用するソフトウェアに伝達するためにライブラリに必要です。

library_config.h現在、オリジナルを含み、config.hユーザーがautotoolsを使用していないときにデフォルトを提供するラッパースクリプトがありますが、そのパッケージ内のマクロの定義を解除しても、gccから再定義の警告が表示されます。

最善のオプションは、そのマクロのないライブラリを用意することだと思います。autotoolsを使用するときに、ライブラリでPACKAGE、PACKAGE_NAMEなどの定義を回避するにはどうすればよいですか。

編集：よりよく説明しようとします。

ライブラリのでAC_CONFIG_HEADERマクロを使用するとき、私は多くの有用な定義を含むファイルを作成します。この定義は、ライブラリ自体（コンパイルされた部分とそのヘッダーファイルの両方）およびクライアントソフトウェアに役立ちます。ただし、必要な便利なマクロと、autotoolsがクライアントソフトウェア構成にも使用されるときに衝突する固定名（PACKAGE、PACKAGE_NAME）を持つ他の汎用定義が混在しているのは残念です。configure.acconfig.hAC_CONFIG_HEADER

私は次のように宣言された関数を持っています：

と組合

次のコードをコンパイルすると：

警告が有効になっている-Wconversionと、次の警告が表示されます。

gcc4が失敗する理由とそれを修正する方法???

基本的なライブラリ カタログ システムを模倣する一連のコードがあります。items という名前の基本クラスがあり、一般的な id、title、および year 変数が定義されており、他の 3 つの派生クラス (DVD、Book、および CD) が定義されています。

ベース 【アイテム】

派生[DVD、本、CD]。

プログラムは実行されますが、次の警告が表示されます。これらを修正する方法がわかりません。

この Web サイトのいくつかの質問は、符号付きと符号なしの型を混在させる場合の落とし穴を明らかにしており、ほとんどのコンパイラはこの型の警告の生成についてうまく機能しているようです。ただし、符号付き定数を符号なし型に割り当てる場合、GCC は気にしないようです! 次のプログラムを検討してください。

以下のように GCC 4.2.1 でコンパイルすると、コンソールに何も出力されません。

結果の実行可能ファイルは、次の出力を生成します。

-30符号付きの値を符号なしの整数変数に割り当てるときに、GCC が警告またはエラー メッセージを生成しない理由はありますyか?

Linux ボックス用のワイヤレス ネットワーク カード ドライバをコンパイルしようとしていますが、Make コマンドで問題が発生しました。コンパイル プロセス中に、通常、コンパイル中の C ファイルの一部に警告が表示されます。警告にもかかわらず、これらのファイルはオブジェクト ファイルにコンパイルできました。

ただし、Make プロセスが rtmp_wext.c というファイルに到達すると、コンパイラは多数の警告を生成し、Make プロセス全体が停止して、エラー 1 の終了ステータスを返しますmake: *** [rtmp_wext.o] Error 1。通常、コンパイルを停止するための C ファイルのエラーが表示されます。これは、コンパイラの警告がファイルをオブジェクト ファイルに変換するのを妨げているように見えるのは初めてです。これは可能ですか、それともコンパイルが失敗した原因は他にありますか?

次の 2 つの警告が表示されます (MacOSX 上の GCC 4.2 を使用):

/Users/az/Programmierung/openlierox/build/Xcode/../../src/main.cpp:154:0 /Users/az/Programmierung/openlierox/build/Xcode/../../src/main .cpp:154: 警告: 'startMainLockDetector()::MainLockDetector' は、そのフィールド 'startMainLockDetector()::MainLockDetector::<anonymous>' のタイプよりも優れた可視性で宣言されました

/Users/az/Programmierung/openlierox/build/Xcode/../../src/main.cpp:154:0 /Users/az/Programmierung/openlierox/build/Xcode/../../src/main .cpp:154: 警告: 'startMainLockDetector()::MainLockDetector' は、ベースの 'Action' よりも可視性が高く宣言されています

このコードでは:

これらの警告が何を意味するのか (可視性は?)、およびそれらを修正する方法が正確にはわかりません。(私はクラス MainLockDetector をその関数に対してのみローカルにしたいと思っています。)

私はすでに他の多くのコンパイラ (clang、GCC 3.*、GCC 4.0、GCC 4.4 など) で同じコードをコンパイルしましたが、このコードに関する警告は一度もありませんでした。

unsigned問題のコードをからにint、そして再コンパイル時にできるだけ多くの変数を変更するという決定を下したところ、次の警告メッセージが表示されました。

問題の行：

このループは60行のコード（空白/角かっこなどを含む）であり、そのgoto中に少なくとも1つの。がありcontinueます。

この場合、GCCがこのループが無限ではないと想定していることに感謝します。なぜなら、無限にループすることは決してないからです。

GCCはここで私に何を伝えようとしていますか？

^{警告の文法は、警告が他の警告のコンテキスト内で取られるべきであることをほぼ示唆していますが、そのコンテキスト内には何もありません。}

[編集] それはすべて完全に私自身のせいです。私はここの質問からいくつかの最適化と警告のオプションを実際に理解せずに盗み、それ以来それらを忘れていました。

-Wunsafe-loop-optimizationsMark Rushakoffの答えを参照してください。さらに、 GCCがループについて仮定を行っているかどうかを明示的に警告するためにも使用しました。http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.htmlを参照してください