lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Stifling "unused" warnings


From: Greg Chicares
Subject: Re: [lmi] Stifling "unused" warnings
Date: Wed, 27 Oct 2021 17:36:07 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

On 10/27/21 12:15 PM, Vadim Zeitlin wrote:
> On Tue, 26 Oct 2021 23:17:46 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> I would like to add a test case for '-Wuninitialized-const-reference'
> GC> to 'miscellany_test.cpp'.
> 
>  Sorry, but how exactly would this work? I don't think we have any tests
> checking for failing compilation in lmi

Correct. Let me show you something I hope to commit soon
(I've already merged the two template functions and
simplified the name they now share):

--8<---8<---8<---8<---8<---8<---8<---8<---8<---8<-
    // Variable neither initialized nor used.
    int a;
    stifle_unused_warning(a);

    // Variable initialized but not used.
    int b {2};
    stifle_unused_warning(b);

    // Variable initialized and used, but only conditionally.
    int c;
#if defined some_undefined_condition
    c = 3;
    std::cout << c << " This should not print" << std::endl;
#endif // defined some_undefined_condition
    stifle_unused_warning(c);

    // Variable initialized and later used...
    int volatile d {4};
    stifle_unused_warning(d);
    // ...but last value not used.
    for(int i = 0; i < 7; ++i)
        {
        d = static_cast<int>(std::clock());
        }
    stifle_unused_warning(d);
-<8---<8---<8---<8---<8---<8---<8---<8---<8---<8--

Running these unit tests only verifies that stifle_unused_warning()
prevents compiler warnings. Their real purpose is documentary: they
demonstrate several different intended use cases.

For {a,b,c}, those tests are straightforward. If I comment out
the stifle_unused_warning() calls, then gcc gives warnings;
with those calls left in place, it gives none.

For 'd', though, I'm trying to write tests to cover the sort
of problem discussed here:
  https://lists.nongnu.org/archive/html/lmi/2021-04/msg00058.html
which clang complained about but gcc didn't. I should probably
just install clang and figure out how to use it, but for the
moment I'm flying blind because gcc refuses to complain here.
Maybe I should go ahead and commit what I've done so far, to
get it out of the way so that I can experiment with clang.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]