Hide Forgot
If we check for failure here, all we can do is return failure to callers, and many of them don't check either. That's because TIOCMGET and TIOCMSET are unlikely to fail. Not worth fixing in RHEL-6; we got bigger fish to fry.
I agree that this is not worth fixing in the code. However, what if there were some sort of directive we could give to Coverity so that it would ignore these problems. Is that possible? If it cannot be done, then this BZ can stay closed.
I'm afraid I can't give you a straight answer, only information you might find useful. Unwanted checkers can be disabled like this: cov-analyze --disable CHECKED_RETURN Risks throwing out the baby with the bathwater :) The sensitivity of CHECKED_RETURN can be tuned like this: cov-analyze --checker-option CHECKED_RETURN:stat_threshold:N where N is the percentage of calls checking the function value required to make Coverity flag the unchecked calls. N defaults to 80, and --aggressiveness-level medium or high reduce that to 55. Models can be used to make Coverity flag all unchecked calls to specific functions. See also Coverity® 7.0.3 Checker Reference, 2.18. CHECKED_RETURN. Most checkers can report false positives. Even correct defect reports may not be worth fixing. Sustained use of Coverity always needs techniques to avoid examining known defects repeatedly. Coverity provides graphical tools for that, but apparently they don't scale up to RHEL's caliber. Coverity's free scanning service we use upstream occasionally provides a basic web interface, which I haven't used myself. I think Paolo has. Our own scanning folks developed simple command-line tools to compare two scans and show fixed or new defect reports. Start here: https://engineering.redhat.com/trac/CoverityScan/wiki/csdiff Linked from https://engineering.redhat.com/trac/CoverityScan/wiki