https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108251
--- Comment #6 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
The analyzer sees the error-handling case in objt_conn, and considers the
execution path where it bails out early due to "t" being NULL i.e.
smp->sess->origin is NULL, and thus conn being initialized to NULL.
At it turns out, ssl_sock_get_ssl_object is defined (in src/ssl_sock.c) as:
SSL *ssl_sock_get_ssl_object(struct connection *conn)
{
struct ssl_sock_ctx *ctx = conn_get_ssl_sock_ctx(conn);
return ctx ? ctx->ssl : NULL;
}
and conn_get_ssl_sock_ctx is defined (in include/haproxy/connection.h) as:
/* retrieves the ssl_sock_ctx for this connection otherwise NULL */
static inline struct ssl_sock_ctx *conn_get_ssl_sock_ctx(struct connection
*conn)
{
if (!conn || !conn->xprt || !conn->xprt->get_ssl_sock_ctx)
return NULL;
return conn->xprt->get_ssl_sock_ctx(conn);
}
Hence it's a false positive: if conn is NULL, then ssl_sock_get_ssl_object will
return NULL.
The TU "sees" the definition of conn_get_ssl_sock_ctx, but only the declaration
of ssl_sock_get_ssl_object, not the latter's declaration.
Without a definition of ssl_sock_get_ssl_object, -fanalyzer can't "know" of the
interaction between "ssl" and "conn" (-fanalyzer doesn't work well with LTO
yet).
Hence it erroneously considers the case that ssl_sock_get_ssl_object could
return non-NULL on a NULL "conn", and sees the deref of conn, which it reports.
