There are only three errors left, of which I am unsure what to do. What is left in error file is specifically

www.viva64.com/en/w:1:1: error: Help: The documentation for all analyzer warnings is available here: https://www.viva64.com/en/w/.
./src/nvim/event/socket.c:255:1: error: V547 Expression 'status == 0' is always false.
./build/src/nvim/auto/funcs.generated.h:127:1: error: V011 Presence of #line directives may cause some diagnostic messages to have incorrect file name and line number.
./src/nvim/quickfix.c:4833:1: warning: V560 A part of conditional expression is always false: qi != save_qi.
./src/nvim/regexp.c:4314:1: warning: V560 A part of conditional expression is always true: status != 1.

, unsure about socket, regexp and quickfix errors. One was reported as vim/vim#2838 and is supposed to be a true error, other two are probably false positives.

./src/nvim/event/socket.c:255:1: error: V547 Expression 'status == 0' is always false.

@bfredl This looks legitimate. I don't see *status getting set in any of the callbacks. connect_cb sets *ret_status. But I would think status != 1 comparison is subject to compiler optimizations, maybe it should look like *(&status) != 1 or should somehow avoid being stack-allocated ...

Is not *&var a perfect candidate for reducing to var in one of the optimization passes? It is not uncommon to have exactly that as a result of macro expansions. To force compiler not optimize that out there is volatile, not *&var hack. (Maybe *((volatile type *)&var), will also work but I am not sure.)

Though I do not think compiler will actually optimize that out. Pointer to status is clearly stored into a structure whis is in turn passed by reference somewhere outside of the current compilation unit. There would need to be a hell lot of flow analysis on linking stage (note: “outside of compilation unit” is libuv library, it basically only has headers and machine code for analysis) to prove that LOOP_PROCESS_EVENT_UNTIL (specifically, loop_poll_events()) may not actually change state. Compilers do not go that far.

@justinmk if it was legitimate, neovim could never possibly connect to a socket... Taking the address of a local variable has a well defined meaning in C, an optimization should not deviate from well-defined behavior. (issue would be if threads or signal handlers are involved, but they are not).

@bfredl Legitimate in the sense that PVS knows about some optimization or other condition that could be a risk.

The second half of my comment addresses that. Passing the address of a local varable down in the stack is well-defined behavior. Optimizers cannot randomly change the meaning of well-defined behavior to achieve performance, otherwise there wouldn't be much point of a language spec.

You don't have to convince me, I don't claim to know what PVS thinks. But I also don't see any reason not to change it to a static variable or something like that, if that eliminates the warning, which could be legitimate for a reason we don't know.

Do you think PVS made a mistake, and why?

I normally just silence those with // -V… comment. BTW, tests succeeded except for QB with

test/functional/eval/timer_spec.lua @ 78
Failure message: test/functional/eval/timer_spec.lua:84: Expected objects to be the same.
Passed in:
(boolean) false
Expected:
(boolean) true
stack traceback:
test/functional/eval/timer_spec.lua:84: in function <test/functional/eval/timer_spec.lua:78>

test/functional/eval/timer_spec.lua @ 88: timers can invoke redraw in blocking getchar() call

which looks like unrelated failure.

@justinmk The PVS warning is a direct falsehood, so it doesn't imply anything to me. Simplest would be to just silence it. Making a variable static which doesn't make use of static behavior is only confusing.

I also do not claim to know how PVS thinks, but it is not the first error where flow analysis clearly cannot grasp the fact that reference to value is passed (or worse, exists before entering function) somewhere where referenced value may be edited.

./src/nvim/event/socket.c:255:1: error: V547 Expression 'status == 0' is always false.

Let's supress this one then.

./build/src/nvim/auto/funcs.generated.h:127:1: error: V011 Presence of #line directives may cause some diagnostic messages to have incorrect file name and line number.

Instead of excluding V011 should we avoid producing #line directives in .generated.* files?