Jeffrey Walton <noloa...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers