Re: conditional jumps based on uninitialized values in IMAP code

[Christoph Ludwig <ludwig@xxxxxxxxxxx>]

On Sat, May 13, 2006 at 10:16:48AM -0400, Thomas Dickey wrote:
> On Sat, 13 May 2006, Christoph Ludwig wrote:
> >**28370** conn->available undefined
> >
> >**28370** conn->available undefined
> >
> >and so on. Where is the available field of the connection structures 
> >supposed
> >to be initialized?
> 
> That appears to be passed back as the return value from a function that's
> chosen at runtime:
> 
> int mutt_socket_readchar (CONNECTION *conn, char *c)
> {
>   if (conn->bufpos >= conn->available)
>   {
>     if (conn->fd >= 0)
>       conn->available = conn->conn_read (conn, conn->inbuf, sizeof 
>       (conn->inbuf>
>     else
> 
> That is, "conn_read" is set in different parts of the program:
> 
> mutt_sasl.c:362:  conn->conn_read = mutt_sasl_conn_read;
> mutt_sasl.c:470:  conn->conn_read = sasldata->msasl_read;
> mutt_socket.c:294:    conn->conn_read = raw_socket_read;
> mutt_ssl.c:119:  conn->conn_read = ssl_socket_read;
> mutt_ssl.c:381:  conn->conn_read = raw_socket_read;
> mutt_ssl_gnutls.c:302:  conn->conn_read = raw_socket_read;
> mutt_tunnel.c:55:  conn->conn_read = tunnel_socket_read;
> 
> One of those functions appears to be returning an uninitialized value.

Thanks. It turns out, valgrind deems the return value of SSL_read() in
ssl_socket_read() (in mutt_ssl.c) uninitialized. Since I already had to
suppress plenty of "uninitialized" messages caused by code in libcrypto and
libssl, I will need to look into those first, it seems.

Thanks again,

Christoph

-- 
FH Worms - University of Applied Sciences
Fachbereich Informatik / Telekommunikation
Erenburgerstr. 19, 67549 Worms, Germany