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