Re: [libvirt] [PATCH 8/8] daemon: Resolve Coverity FORWARD_NULL

2014-09-15 Thread Martin Kletzander
On Sat, Sep 13, 2014 at 09:27:45AM -0400, John Ferlan wrote: Coverity complains that the comparison: if (nfds nfds ((int)!!sock_path + (int)!!sock_path_ro)) could mean 'sock_path' is NULL. Later in virNetSocketNewListenUNIX there's a direct dereference of path in the error path: if

Re: [libvirt] [PATCH 8/8] daemon: Resolve Coverity FORWARD_NULL

2014-09-15 Thread John Ferlan
On 09/15/2014 04:36 AM, Martin Kletzander wrote: On Sat, Sep 13, 2014 at 09:27:45AM -0400, John Ferlan wrote: Coverity complains that the comparison: if (nfds nfds ((int)!!sock_path + (int)!!sock_path_ro)) could mean 'sock_path' is NULL. Later in virNetSocketNewListenUNIX there's a

Re: [libvirt] [PATCH 8/8] daemon: Resolve Coverity FORWARD_NULL

2014-09-15 Thread Martin Kletzander
On Mon, Sep 15, 2014 at 07:49:09AM -0400, John Ferlan wrote: On 09/15/2014 04:36 AM, Martin Kletzander wrote: On Sat, Sep 13, 2014 at 09:27:45AM -0400, John Ferlan wrote: Coverity complains that the comparison: if (nfds nfds ((int)!!sock_path + (int)!!sock_path_ro)) could mean 'sock_path'

[libvirt] [PATCH 8/8] daemon: Resolve Coverity FORWARD_NULL

2014-09-13 Thread John Ferlan
Coverity complains that the comparison: if (nfds nfds ((int)!!sock_path + (int)!!sock_path_ro)) could mean 'sock_path' is NULL. Later in virNetSocketNewListenUNIX there's a direct dereference of path in the error path: if (path[0] != '@') A bit of sleuthing proves that upon entry to