On Mon, 7 Jan 2019 at 10:22, Gerd Hoffmann <kra...@redhat.com> wrote: > > On Thu, Jan 03, 2019 at 05:31:13AM -0800, Li Qiang wrote: > > Spotted by Coverity: CID 1397070
> > #ifdef CONFIG_INOTIFY1 > > @@ -682,6 +683,7 @@ static void usb_mtp_object_readdir(MTPState *s, > > MTPObject *o) > > usb_mtp_add_child(s, o, entry->d_name); > > } > > closedir(dir); > > + close(fd); > > Not fully sure this is correct. > > The fdopendir manpage says the app should not use fd any more after > successfully calling fdopendir(), and I assumed that includes calling > close(). Yes. The POSIX spec is clearer: http://pubs.opengroup.org/onlinepubs/9699919799/functions/fdopendir.html "Upon successful return from fdopendir(), the file descriptor is under the control of the system, and if any attempt is made to close the file descriptor, or to modify the state of the associated description, other than by means of closedir(), readdir(), readdir_r(), rewinddir(), or seekdir(), the behavior is undefined. Upon calling closedir() the file descriptor shall be closed." > But I've seen the Coverity message warning this one too, so > maybe I'm wrong ... If coverity insists on a close(fd) then that's a coverity bug :-) thanks -- PMM
