There is no risk to resource leak i think, becase: 1. dup() in first statement (TTY controlling) duplicate console fd, so marked as a resource leak a console fd is a false positive - primo: it's console handler, secundo: dup() is using for child/fork processes.
2. dup() in second statement for /dev/null clone for the same reason as above. Here we can't close file descriptors created by dup() - *I think*. So we can ignore that and mark as Intentional solution. Please verify my opinion. ---- Michał Kulling 2014-02-11 22:30 GMT+01:00 Petter Reinholdtsen <p...@hungry.com>: > [Michał Kulling] >> Coverity mark my changes as resource leak because I'm not assign >> descriptor returned from dup(). > > No, it mark them as resource leaks because the resources leak. The > opened file descriptor isn't closed. I suspect things will fail it it > is closed, so I have not tried to close it. But I have not > investigated either. > > The previous patch made it easier to see in Coverity exactly where > things go wrong, which is why I applied them. Did you expect them to > get rid of the leak? > > -- > Happy hacking > Petter Reinholdtsen >
