Re: Clang 3.3 Analyzer Results

Jeffrey Walton <noloader(at)gmail(dot)com> writes:
> I did not check any with the long path lengths, but the
> `pqsecure_write` in fe-secure.c looks valid to me. `spinfo` is
> declared, Clang builds/finds the path, then the unitializaed `spinfo`
> is used in `RESTORE_SIGPIPE(conn, spinfo);`.

It's junk AFAICS, though I will agree that seeing that it's junk is
probably beyond clang's powers of analysis. To make use of an
uninitialized value, we'd have to arrive at RESTORE_SIGPIPE with
SIGPIPE_MASKED false, after either not having passed through
DISABLE_SIGPIPE at all, or having passed through it with SIGPIPE_MASKED
true. The first case can be dismissed out of hand. The second case
is a bit harder, because there is a place in between that clears
sigpipe_flag and thus could possibly cause SIGPIPE_MASKED to become
false. However, we immediately jump back and re-execute DISABLE_SIGPIPE
after doing that, so there's no bug. But that control flow is ugly
enough that I'm not surprised clang can't see through it ...

Having said all that, though, I'm a bit surprised that we don't get
possibly-uninitialized-variable warnings from gcc here. In older
gcc versions the address-takings would have disabled warnings, but
I thought that that didn't discourage newer versions from whining.

regards, tom lane