https://bugs.kde.org/show_bug.cgi?id=502359
--- Comment #3 from Mark Wielaard <m...@klomp.org> --- Looks good, but some nitpicks. I like extended commit messages, this doesn't really explain why we picked "yes" (it is because the default should work for most). It also doesn't explain what happens when the number isn't 0/1/2 (they are handled like with "high"). Not a fan of having to remember what numbers stand for. If at all possible please define and use something like MODIFY_FD_NO/YES/HIGH. The \ don't really line up in the POST_newFd_RES define (nitpick) For the testcase it would probably be good to use dup The comment says "redirect stdout as stderr" dup2 (2, 1); does that indeed, dup stderr (2) into stdout (1) But for the test it would be better to do it as close (1); dup (2); Since dup (2) is supposed to pick the lowest but with =high it would pick some high fd number with =yes it should pick 1 since that is the lowest (just closed). You probably also want to test that. So write something to file descriptor 1 and see it appear in stderr (so you can check with track_yes.stderr.exp) And stdout should still be empty. +cleanup: rm -f foobad.txt foobar.txt For track_yes.vgtest seems not needed. You don't create those files in this test. -- You are receiving this mail because: You are watching all bug changes.
