Date: Mon, 4 Jun 2018 11:48:15 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Matthew Macy <mat.macy@gmail.com>, Theron <theron.tarigo@gmail.com> Cc: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: Re: how to deal with variable set but not used warnings? Message-ID: <YTOPR0101MB0953AAEA38D9EB0B20BD29B2DD670@YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <CAPrugNqWQOeX=DAQJMsiMGX1m5-RqnE4DaMv4=HiM8ZNoEsafg@mail.gmail.com> References: <YTOPR0101MB09532BCE14780B64270D07E0DD600@YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM> <CANCZdfryUsjsqn7izpX9BM354-9013oazxiKAz-5cSFj7m5p0A@mail.gmail.com> <df803751-2827-a1b2-7f79-1facf812467c@gmail.com>, <CAPrugNqWQOeX=DAQJMsiMGX1m5-RqnE4DaMv4=HiM8ZNoEsafg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Macy wrote: >On Sun, Jun 3, 2018 at 2:40 PM, Theron <theron.tarigo@gmail.com> wrote: >>> 4. Disable the stupid warning in the Makefile / build system. If you do= n't >>> care, and there's a good reason for what you are doing (sounds like the= re >>> is), better to just disable the warning as so much useless noise. >>> >>> Warner >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >> >> Or possibly, alongside a comment as in (3), use one of these: >> 5 - Disable warning pragma - >> http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html >> 6 - Use __attribute__((unused)) - > https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#Common= -Variable-Attributes > > >There is already an __unused alias for #6. It's what I've used to >annotate variables that are only used by INVARIANTS builds. It >legitimately finds a bunch of dead code. However, 90+% of the >instances of the warning are not interesting. Ok. I didn't realize that __unused would work for this case of "set but not= used" but I just tried it on the older gcc48 I have lying around and it worked. (clang doesn't seem to warn or care about these cases.) I may use this, since I avoid messing with the make files like the plague. Thanks, rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTOPR0101MB0953AAEA38D9EB0B20BD29B2DD670>