Cara menonaktifkan peringatan GCC untuk beberapa baris kode


220

Dalam Visual C ++, dimungkinkan untuk digunakan #pragma warning (disable: ...). Saya juga menemukan bahwa di GCC Anda dapat mengganti setiap flag kompiler file . Bagaimana saya bisa melakukan ini untuk "baris berikutnya", atau dengan push / pop semantik di sekitar area kode menggunakan GCC?


1
kemungkinan duplikat menonaktifkan peringatan khusus di gcc - Ups, sebenarnya pertanyaan itu sendiri adalah sebuah penipuan (tetapi tidak ditutup). Itu hanya kebetulan yang muncul di bawah "Terkait". Bagaimanapun, ini telah ditanyakan dan dijawab beberapa kali pada SO.
Tyler McHenry

1
@ paxdiablo: Saya melakukan sebaliknya. Saya telah mendongkrak tingkat peringatan sangat tinggi, dan ingin memeras peringatan baris demi baris yang telah saya verifikasi baik-baik saja.
Matt Joiner

4
@ Tyler McHenry: Jika Anda memeriksa dengan lebih hati-hati, Anda mungkin mencatat bahwa pertanyaan yang ditautkan berisi solusi per file, tepatnya yang saya sebutkan dalam pertanyaan saya sendiri tidak memuaskan (saya bahkan mencuri tautannya).
Matt Joiner

6
@paxdiablo, kompiler memberikan positif palsu, kadang-kadang Anda ingin mengkompilasi dengan -Werror tetapi tidak memiliki positif palsu ini memblokir membangun. jadi menonaktifkan kasus spesifik dan berkomentar mengapa - masuk akal dalam beberapa kasus. Ada juga kasus-kasus lain di mana ini bisa berguna - seperti kode penghasil otomatis yang menghasilkan peringatan yang tidak berbahaya yang tidak begitu mudah untuk masuk dan diubah (karena kode dihasilkan), meskipun dalam kasus itu penonaktifan per file lebih cenderung solusinya.
ideasman42

Jawaban:


221

Tampaknya ini bisa dilakukan . Saya tidak dapat menentukan versi GCC yang ditambahkan, tetapi sekitar sebelum Juni 2010.

Ini sebuah contoh:

#pragma GCC diagnostic error "-Wuninitialized"
    foo(a);         /* error is given for this one */
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wuninitialized"
    foo(b);         /* no diagnostic for this one */
#pragma GCC diagnostic pop
    foo(c);         /* error is given for this one */
#pragma GCC diagnostic pop
    foo(d);         /* depends on command line options */

14
satu pushdan dua pops - mungkin yang lain pushdi awal hilang?
jurang.7

37
"#pragma GCC push diagnostik #pragma GCC diagnostik pop Menyebabkan GCC mengingat status diagnostik pada setiap push, dan mengembalikan ke titik itu di setiap pop. Jika pop tidak memiliki push yang cocok, opsi baris perintah dikembalikan. " - dari manual GCC: gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
bobpaul

11
Untuk referensi, gcc versi 4.4.3 mendukung kesalahan / peringatan / diabaikan, tetapi tidak mendorong / pop
frankster

12
Versi pertama GCC yang memiliki push / pop diagnostik adalah GCC 4.6.4 . Saya menentukan ini dengan melihat bagian Diagnostic-Pragmas.html # Diagnostic-Pragmas untuk setiap versi GCC
bitek

5
Sayang sekali ini tidak bekerja dalam praktek. Dalam beberapa kasus, ini menghasilkan lebih banyak peringatan. Atau mungkin, lebih tepatnya, itu tidak berhasil dalam praktik untuk GCC 4.7 hingga 5.1. Lihat, misalnya, GCC tidak menghormati 'pragma GCC diagnostik' untuk membungkam peringatan .
jww

108

Untuk menjaring semuanya, ini adalah contoh menonaktifkan sementara peringatan:

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-result"
    write(foo, bar, baz);
#pragma GCC diagnostic pop

Anda dapat memeriksa dokumentasi GCC pada pragma diagnostik untuk detail lebih lanjut.


2
Seharusnya berhasil, tetapi saya gcc-4.9hanya mengabaikan baris ini sepenuhnya.
Aleksei Petrenko

31

TL; DR : Jika itu berfungsi, hindari, atau gunakan specifier seperti __attribute__, sebaliknya _Pragma.

Ini adalah versi singkat dari artikel blog saya Suppressing Warnings in GCC and Clang .

Pertimbangkan yang berikut ini Makefile

CPPFLAGS:=-std=c11 -W -Wall -pedantic -Werror

.PHONY: all
all: puts

untuk membangun puts.ckode sumber berikut

#include <stdio.h>

int main(int argc, const char *argv[])
{
    while (*++argv) puts(*argv);
    return 0;
}

Ini tidak akan dikompilasi karena argctidak digunakan, dan pengaturannya hardcore ( -W -Wall -pedantic -Werror).

Ada 5 hal yang bisa Anda lakukan:

  • Tingkatkan kode sumber, jika mungkin
  • Gunakan specifier deklarasi, seperti __attribute__
  • Menggunakan _Pragma
  • Menggunakan #pragma
  • Gunakan opsi baris perintah.

Memperbaiki sumbernya

Upaya pertama harus memeriksa apakah kode sumber dapat ditingkatkan untuk menghilangkan peringatan. Dalam hal ini kami tidak ingin mengubah algoritma hanya karena itu, seperti argcyang berlebihan dengan !*argv( NULLsetelah elemen terakhir).

Menggunakan specifier deklarasi, seperti __attribute__

#include <stdio.h>

int main(__attribute__((unused)) int argc, const char *argv[])
{
    while (*++argv) puts(*argv);
    return 0;
}

Jika Anda beruntung, standar menyediakan spek untuk situasi Anda, misalnya _Noreturn.

__attribute__adalah ekstensi GCC berpemilik (didukung oleh Dentang dan beberapa kompiler lain armccjuga) dan tidak akan dipahami oleh banyak kompiler lain. Masukkan ke __attribute__((unused))dalam makro jika Anda ingin kode portabel.

_Pragma operator

_Pragmadapat digunakan sebagai alternatif #pragma.

#include <stdio.h>

_Pragma("GCC diagnostic push")
_Pragma("GCC diagnostic ignored \"-Wunused-parameter\"")

int main(int argc, const char *argv[])
{
    while (*++argv) puts(*argv);
    return 0;
}
_Pragma("GCC diagnostic pop")

Keuntungan utama dari _Pragmaoperator adalah Anda bisa memasukkannya ke dalam makro, yang tidak mungkin dengan #pragmaarahan.

Kelemahan: Ini hampir nuklir taktis, karena ia bekerja berdasarkan garis daripada berbasis deklarasi.

The _PragmaOperator diperkenalkan di C99.

#pragma pengarahan.

Kami dapat mengubah kode sumber untuk menekan peringatan untuk wilayah kode, biasanya seluruh fungsi:

#include <stdio.h>

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-parameter"
int main(int argc, const char *argv[])
{
    while (*++argc) puts(*argv);
    return 0;
}
#pragma GCC diagnostic pop

Kelemahan: Ini hampir nuklir taktis, karena ia bekerja berdasarkan garis daripada berbasis deklarasi.

Perhatikan bahwa sintaksis serupa ada di dentang .

Menekan peringatan pada baris perintah untuk satu file

Kita bisa menambahkan baris berikut ke Makefileuntuk menekan peringatan khusus untuk put:

CPPFLAGS:=-std=c11 -W -Wall -pedantic -Werror

.PHONY: all
all: puts

puts.o: CPPFLAGS+=-Wno-unused-parameter

Ini mungkin tidak ingin Anda inginkan dalam kasus khusus Anda, tetapi mungkin membantu bacaan lain yang berada dalam situasi yang sama.


2
re: improving the sourceitu juga akan berfungsi untuk mengubah deklarasi main menjadi int main(int, const char* argv[]) { ... }dengan tidak memberikan argumen nama, Anda mengatakan kepada kompiler itu akan tidak digunakan.
Jesse Chisholm

1
@JesseChisholm menghilangkan nama parameter pada definisi fungsi tidak dimungkinkan. Lihat 6.9.1 Definisi fungsi ISO / IEC9899, ​​§5 "Jika deklarator menyertakan daftar tipe parameter, deklarasi masing-masing parameter harus menyertakan pengidentifikasi [...]" Dan dengan benar kode tersebut akan ditolak gccjuga clang.
Christian Hujer

1
Pola lain adalah dengan hanya melakukan gips variabel untuk membatalkan. Bahkan, dalam proyek saya telah melihat makro berikut: #define UNUSED(x) ((void)x)digunakan untuk membungkam peringatan. Saya pikir itu di ReactOS?
Paul Stelian

1
Saya tidak berpikir Anda perlu backslash setelah ini, bukan? _Pragma("GCC diagnostic pop") \ seharusnya _Pragma("GCC diagnostic pop")saya pikir.
Gabriel Staples

1
@GabrielStaples Benar, terima kasih telah memperhatikan, saya telah memperbarui jawabannya.
Christian Hujer

20
#define DIAG_STR(s) #s
#define DIAG_JOINSTR(x,y) DIAG_STR(x ## y)
#ifdef _MSC_VER
#define DIAG_DO_PRAGMA(x) __pragma (#x)
#define DIAG_PRAGMA(compiler,x) DIAG_DO_PRAGMA(warning(x))
#else
#define DIAG_DO_PRAGMA(x) _Pragma (#x)
#define DIAG_PRAGMA(compiler,x) DIAG_DO_PRAGMA(compiler diagnostic x)
#endif
#if defined(__clang__)
# define DISABLE_WARNING(gcc_unused,clang_option,msvc_unused) DIAG_PRAGMA(clang,push) DIAG_PRAGMA(clang,ignored DIAG_JOINSTR(-W,clang_option))
# define ENABLE_WARNING(gcc_unused,clang_option,msvc_unused) DIAG_PRAGMA(clang,pop)
#elif defined(_MSC_VER)
# define DISABLE_WARNING(gcc_unused,clang_unused,msvc_errorcode) DIAG_PRAGMA(msvc,push) DIAG_DO_PRAGMA(warning(disable:##msvc_errorcode))
# define ENABLE_WARNING(gcc_unused,clang_unused,msvc_errorcode) DIAG_PRAGMA(msvc,pop)
#elif defined(__GNUC__)
#if ((__GNUC__ * 100) + __GNUC_MINOR__) >= 406
# define DISABLE_WARNING(gcc_option,clang_unused,msvc_unused) DIAG_PRAGMA(GCC,push) DIAG_PRAGMA(GCC,ignored DIAG_JOINSTR(-W,gcc_option))
# define ENABLE_WARNING(gcc_option,clang_unused,msvc_unused) DIAG_PRAGMA(GCC,pop)
#else
# define DISABLE_WARNING(gcc_option,clang_unused,msvc_unused) DIAG_PRAGMA(GCC,ignored DIAG_JOINSTR(-W,gcc_option))
# define ENABLE_WARNING(gcc_option,clang_option,msvc_unused) DIAG_PRAGMA(GCC,warning DIAG_JOINSTR(-W,gcc_option))
#endif
#endif

Ini harus melakukan trik untuk gcc, dentang dan msvc

Dapat dipanggil dengan mis:

DISABLE_WARNING(unused-variable,unused-variable,42)
[.... some code with warnings in here ....]
ENABLE_WARNING(unused-variable,unused-variable,42)

lihat https://gcc.gnu.org/onlinedocs/cpp/Pragmas.html , http://clang.llvm.org/docs/UsersManual.html#controlling-diagnostics-via-pragmas dan https://msdn.microsoftoft .com / de-DE / library / d9x1s805.aspx untuk lebih jelasnya

Anda memerlukan setidaknya versi 4.02 untuk menggunakan pragma semacam ini untuk gcc, tidak yakin tentang msvc dan dentang tentang versi.

Sepertinya penanganan push pop pragma untuk gcc sedikit rusak. Jika Anda mengaktifkan peringatan lagi, Anda masih mendapatkan peringatan untuk blok yang ada di dalam blok DISABLE_WARNING / ENABLE_WARNING. Untuk beberapa versi gcc berfungsi, untuk sebagian tidak.


3
Anda da MVP nyata
zeboidlund

19
#pragma GCC diagnostic ignored "-Wformat"

Ganti "-Wformat" dengan nama bendera peringatan Anda.

AFAIK tidak ada cara untuk menggunakan push / pop semantik untuk opsi ini.


4
Sayang sekali ini tidak bekerja dalam praktek. Dalam beberapa kasus, ini menghasilkan lebih banyak peringatan. Atau mungkin, lebih tepatnya, itu tidak berhasil dalam praktik untuk GCC 4.7 hingga 5.1. Lihat, misalnya, GCC tidak menghormati 'pragma GCC diagnostik' untuk membungkam peringatan .
jww

6

Saya memiliki masalah yang sama dengan perpustakaan eksternal seperti header ROS. Saya suka menggunakan opsi berikut di CMakeLists.txt untuk kompilasi yang lebih ketat:

set(CMAKE_CXX_FLAGS "-std=c++0x -Wall -Wextra -Wstrict-aliasing -pedantic -Werror -Wunreachable-code ${CMAKE_CXX_FLAGS}")

Namun melakukan ini menyebabkan semua jenis kesalahan pedantic di perpustakaan yang disertakan secara eksternal juga. Solusinya adalah untuk menonaktifkan semua peringatan dahsyat sebelum Anda menyertakan perpustakaan eksternal dan mengaktifkan kembali seperti ini:

//save compiler switches
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wpedantic"

//Bad headers with problem goes here
#include <ros/ros.h>
#include <sensor_msgs/LaserScan.h>

//restore compiler switches
#pragma GCC diagnostic pop

2
Bukankah ini sebaiknya ditangani dengan direktori sistem gcc ?
Merah XIII

@RedXIII - ya, itu opsi jika Anda dapat membuat daftar direktori seperti itu dan tentukan dalam baris perintah gcc. Namun berkali-kali kompiler dipanggil dalam-dalam pipeline atau Anda tidak memiliki banyak kontrol atas bagaimana orang lain harus mengkompilasi kode Anda. Dalam kasus-kasus di atas mungkin merupakan solusi yang lebih baik.
Shital Shah

5

Saya tahu pertanyaannya adalah tentang GCC, tetapi untuk orang yang mencari cara melakukan ini di kompiler lain dan / atau banyak ...

TL; DR

Anda mungkin ingin melihat Hedley , yang merupakan header domain publik C / C ++ tunggal yang saya tulis yang memberikan banyak hal untuk Anda. Saya akan memasukkan bagian singkat tentang cara menggunakan Hedley untuk semua ini di akhir posting ini.

Menonaktifkan peringatan

#pragma warning (disable: …) memiliki padanan dalam kebanyakan kompiler:

  • MSVC: #pragma warning(disable:4996)
  • GCC: di #pragma GCC diagnostic ignored "-W…"mana elipsis adalah nama peringatan; misalnya , #pragma GCC diagnostic ignored "-Wdeprecated-declarations.
  • dentang: #pragma clang diagnostic ignored "-W…". Sintaksisnya pada dasarnya sama dengan GCC, dan banyak dari nama peringatan itu sama (walaupun banyak yang tidak).
  • Intel C Compiler: Gunakan sintaks MSVC, tetapi perlu diingat bahwa nomor peringatan sama sekali berbeda. Contoh: #pragma warning(disable:1478 1786).
  • PGI: Ada diag_suppresspragma:#pragma diag_suppress 1215,1444
  • TI: Ada diag_suppresspragma dengan sintaks yang sama (tetapi nomor peringatan berbeda!) Dengan PGI:pragma diag_suppress 1291,1718
  • Oracle Developer Studio (suncc): ada error_messagespragma. Mengganggu, peringatan berbeda untuk kompiler C dan C ++. Kedua menonaktifkan ini pada dasarnya peringatan yang sama:
    • C: #pragma error_messages(off,E_DEPRECATED_ATT,E_DEPRECATED_ATT_MESS)
    • C ++: #pragma error_messages(off,symdeprecated,symdeprecated2)
  • IAR: juga menggunakan diag_suppressseperti PGI dan TI, tetapi sintaksnya berbeda. Beberapa nomor peringatannya sama, tetapi saya yang lain telah menyimpang:#pragma diag_suppress=Pe1444,Pe1215
  • Pelles C: mirip dengan MSVC, meskipun sekali lagi angkanya berbeda #pragma warn(disable:2241)

Untuk sebagian besar kompiler, sebaiknya memeriksa versi kompiler sebelum menonaktifkannya, jika tidak, Anda hanya akan memicu peringatan lain. Misalnya, GCC 7 menambahkan dukungan untuk -Wimplicit-fallthroughperingatan, jadi jika Anda peduli dengan GCC sebelum 7, Anda harus melakukan sesuatu seperti

#if defined(__GNUC__) && (__GNUC__ >= 7)
#  pragma GCC diagnostic ignored "-Wimplicit-fallthrough"
#endif

Untuk dentang dan kompiler yang didasarkan pada dentang seperti versi yang lebih baru dari XL C / C ++ dan armclang, Anda dapat memeriksa untuk melihat apakah kompiler tahu tentang peringatan tertentu menggunakan __has_warning()makro.

#if __has_warning("-Wimplicit-fallthrough")
#  pragma clang diagnostic ignored "-Wimplicit-fallthrough"
#endif

Tentu saja Anda juga harus memeriksa untuk melihat apakah __has_warning()makro ada:

#if defined(__has_warning)
#  if __has_warning("-Wimplicit-fallthrough")
#    pragma clang diagnostic ignored "-Wimplicit-fallthrough"
#  endif
#endif

Anda mungkin tergoda untuk melakukan sesuatu seperti

#if !defined(__has_warning)
#  define __has_warning(warning)
#endif

Jadi Anda bisa menggunakan __has_warningsedikit lebih mudah. Dentang bahkan menyarankan sesuatu yang mirip dengan __has_builtin()makro di manual mereka. Jangan lakukan ini . Kode lain mungkin memeriksa __has_warningdan kembali memeriksa versi kompiler jika tidak ada, dan jika Anda menentukan __has_warningAnda akan memecahkan kode mereka. Cara yang tepat untuk melakukan ini adalah membuat makro di namespace Anda. Sebagai contoh:

#if defined(__has_warning)
#  define MY_HAS_WARNING(warning) __has_warning(warning)
#else
#  define MY_HAS_WARNING(warning) (0)
#endif

Maka Anda dapat melakukan hal-hal seperti

#if MY_HAS_WARNING(warning)
#  pragma clang diagnostic ignored "-Wimplicit-fallthrough"
#elif defined(__GNUC__) && (__GNUC__ >= 7)
#  pragma GCC diagnostic ignored "-Wimplicit-fallthrough"
#endif

Mendorong dan bermunculan

Banyak kompiler juga mendukung cara untuk mendorong dan mengeluarkan peringatan ke tumpukan. Misalnya, ini akan menonaktifkan peringatan pada GCC untuk satu baris kode, lalu mengembalikannya ke status sebelumnya:

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdeprecated"
call_deprecated_function();
#pragma GCC diagnostic pop

Tentu saja tidak ada banyak kesepakatan di antara kompiler tentang sintaks:

  • GCC 4.6+: #pragma GCC diagnostic push/#pragma GCC diagnostic pop
  • dentang: #pragma clang diagnostic push/#pragma diagnostic pop
  • Intel 13+ (dan mungkin sebelumnya): #pragma warning(push)/#pragma warning(pop)
  • MSVC 15+ (VS 9.0 / 2008): #pragma warning(push)/#pragma warning(pop)
  • ARM 5.6+: #pragma push/#pragma pop
  • TI 8.1+: #pragma diag_push/#pragma diag_pop
  • Pelles C 2.90+ (dan mungkin lebih awal): #pragma warning(push)/#pragma warning(pop)

Jika memori berfungsi, untuk beberapa versi GCC yang sangat lama (seperti 3.x, IIRC) pragma push / pop harus berada di luar fungsi.

Menyembunyikan detail berdarah

Untuk sebagian besar kompiler dimungkinkan untuk menyembunyikan logika di balik makro yang menggunakan _Pragma, yang diperkenalkan pada C99. Bahkan dalam mode non-C99, kebanyakan kompiler mendukung _Pragma; pengecualian besar adalah MSVC, yang memiliki __pragmakata kunci sendiri dengan sintaks yang berbeda. Standar _Pragmamengambil string, versi Microsoft tidak:

#if defined(_MSC_VER)
#  define PRAGMA_FOO __pragma(foo)
#else
#  define PRAGMA_FOO _Pragma("foo")
#endif
PRAGMA_FOO

Secara kasar setara, setelah diproses, untuk

#pragma foo

Ini memungkinkan kami membuat makro sehingga kami dapat menulis kode seperti

MY_DIAGNOSTIC_PUSH
MY_DIAGNOSTIC_DISABLE_DEPRECATED
call_deprecated_function();
MY_DIAGNOSTIC_POP

Dan sembunyikan semua pemeriksaan versi jelek dalam definisi makro.

Cara mudah: Hedley

Sekarang setelah Anda memahami mekanisme cara melakukan hal-hal seperti ini dengan mudah sambil menjaga kode Anda tetap bersih, Anda memahami apa salah satu proyek saya, Hedley . Alih-alih menggali melalui banyak dokumentasi dan / atau menginstal versi sebanyak mungkin kompiler untuk mengujinya, Anda bisa memasukkan Hedley (ini adalah header domain C / C ++ publik tunggal) dan selesai melakukannya. Sebagai contoh:

#include "hedley.h"

HEDLEY_DIAGNOSTIC_PUSH
HEDLEY_DIAGNOSTIC_DISABLE_DEPRECATED
call_deprecated();
HEDLEY_DIAGNOSTIC_POP

Akan menonaktifkan peringatan tentang memanggil fungsi yang sudah tidak digunakan lagi di GCC, dentang, ICC, PGI, MSVC, TI, IAR, ODS, Pelles, dan mungkin yang lain (saya mungkin tidak akan repot memperbarui jawaban ini ketika saya memperbarui Hedley). Dan, pada kompiler yang tidak dikenal berfungsi, makro tidak akan diproses apa-apa, jadi kode Anda akan terus bekerja dengan kompiler apa pun. Tentu saja HEDLEY_DIAGNOSTIC_DISABLE_DEPRECATEDbukan satu-satunya peringatan yang diketahui Hedley, juga tidak menonaktifkan peringatan yang bisa dilakukan Hedley, tapi mudah-mudahan Anda mendapatkan idenya.


3

Alih-alih membungkam peringatan, gaya gcc biasanya menggunakan konstruksi standar C atau __attribute__ekstensi untuk memberi tahu kompiler lebih banyak tentang niat Anda. Misalnya, peringatan tentang penugasan yang digunakan sebagai suatu kondisi ditekan dengan menempatkan penugasan dalam tanda kurung, yaitu if ((p=malloc(cnt)))bukannya if (p=malloc(cnt)). Peringatan tentang argumen fungsi yang tidak digunakan dapat ditekan oleh beberapa hal aneh yang __attribute__tidak pernah saya ingat, atau dengan penugasan sendiri, dll. Tetapi secara umum saya lebih suka menonaktifkan opsi peringatan yang menghasilkan peringatan untuk hal-hal yang akan terjadi dalam kode yang benar secara global.


2
Mungkin begitu. Maksud saya bukan untuk membuktikan pola kasus umum, melainkan pengamatan tentang apa filosofi gcc tentang penindasan peringatan tampaknya.
R .. GitHub BERHENTI MEMBANTU ICE

kompiler berperilaku berbeda tanpa peringatan dengan tanda kurung ditambahkan?!?! ?? !!!! WOW! Itu tidak terduga.
Jason S

1
@JasonS parens tidak mengubah peringatan perilaku compiler, apa yang dilakukannya adalah mengubah semantik pernyataan itu. Paren tambahan membuat kompiler menyelesaikan tugas dan mempertahankan nilai akhirnya sebagai ekspresi, yang tidak layak diberi peringatan. Jika Anda ingin kejelasan, Anda bisa mengatakan if ((p=malloc(cnt)) != NULL) ...itulah yang dilakukan kompiler di belakang layar.
Jesse Chisholm

@JesseChisholm: Saya rasa penjelasan Anda tidak akurat.
R .. GitHub BERHENTI MEMBANTU ICE

3

Bagi mereka yang menemukan halaman ini mencari cara untuk melakukan ini di IAR, coba ini:

#pragma diag_suppress=Pe177
void foo1( void )
{
   /* The following line of code would normally provoke diagnostic 
      message #177-D: variable "x" was declared but never referenced.
      Instead, we have suppressed this warning throughout the entire 
      scope of foo1(). 
   */
   int x;
}
#pragma diag_default=Pe177

Lihat http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0472m/chr1359124244797.html untuk referensi.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.