Hi Xiang,
Yes, since there are few warnings it is better to fix them.
BR,
Alan
On 4/1/20, Xiang Xiao <xiaoxiang781...@gmail.com> wrote:
> On Thu, Apr 2, 2020 at 1:25 AM Gregory Nutt <spudan...@gmail.com> wrote:
>>
>>
>> > I was able to do this once before:
>> >
>> > #if !defined(TODO)
>> > # if !defined(NO_PRINT_TODOS)
>> > # define DO_PRAGMA(x) _Pragma (#x)
>> > # define TODO(x) DO_PRAGMA(message ("TODO - " #x))
>> > # else
>> > # define TODO(x)
>> > # endif
>> > #endif
>> >
>> > IIRC it allowed me to print compiler output that was not treated as
>> > warnings
>> > then add -Werror= and treat all warnings as errors.
>>
>> This is a little different topic. You are talking about conditionally
>> disabling some of the warnings?
>>
>> I was asking a different question about checking for new warnings in the
>> PR check builds. Let me give the specific example. I had this error in
>> the code:
>>
>> ret - nxsem_wait(&sem);
>> if (ret < 0)
>> {
>> ...
>> }
>>
>> The warning was that the computed value was not used in the line before
>> the test annd then that 'ret' was not initialized in the test. Both
>> were warnings and the code passed the PR check build successfully. But
>> it is clearly wrong; that should have been '=' and not '-' in the line
>> before the test;. If we were to detect new warnings in the builds, then
>> this could have been caught.
>>
>> If we had no warnings in the system other than those generated by
>> #warning, then your suggestion would a good one and maybe we will need
>> to do that down the road.
>>
>> There are many places with REVISIT in the comments. It would nice if
>> those could be made visible as well. REVISIT is the key word for
>> flagging issues in the code (although I am sure some people may have
>> used TODO as well).
>>
>
> Almost warning come from #warning, we can:
> 1.Add -Wno-cpp to disable #warning for precheck/nightly build:
>
> https://stackoverflow.com/questions/9793293/how-do-i-disable-warning-message-in-gcc
> 2.Fix the remaining real warnning
> 3.Enable -Werror for precheck/nightly build
>
> The suggestion from David is also valuable option for item 1, since
> too much warning also block the developer find the real issue in daily
> work. It is always good to enable people find the bug as early as
> possible.
>
>> Greg
>>
>>
>
