On Tue, 4 Nov 2014, David Chisnall wrote:

On 4 Nov 2014, at 10:28, Stefan Farfeleder <stef...@freebsd.org> wrote:

Shouldn't Coverity understand that err doesn't return?

err() is marked as __dead2, which expands to __attribute__((__noreturn__)).  If 
Coverity doesn't know that __attribute__((__noreturn__)) functions don't 
return, then that's a Coverity bug and they should fix it (if we're not 
expanding __dead3 to __attribute__((__noreturn__)) for Coverity, then that's a 
sys/cdefs.h bug and should be fixed there).

__dead3 would be the gcc-3 syntax for __dead2 if that were different.  Since
gcc only changed the syntax for non-returning functions once, __dead3 doesn't
exist.  You probably mean __dead2.

<sys/cdefs.h> is indeed broken for lint and some other cases.  It defines
__dead2 as nothing for lint.  This shouldn't be a problem for primitive
lints since __dead2 is only a hint (not so for some other things that
are defined away), but it prevents any line that supports gcc extensions
from seeing the defined-away attributes.

__dead2 is also defined away unless the compiler is gcc >= 2.5 or any
__INTEL_COMPILER (do any __INTEL_COMPILERs still exist?).  Coverity
would have to pretend to be gcc >= 2.5 to see the gcc attributes.  clang
pretends this, but INTEL_COMPILER doesn't.

Some other attributes are ifdefed more orthogonally but still messily
using macros like __CC_SUPPORTS_INLINE.  You still need a mess of ifdefs
to determine if the compiler supports the feature.  The mess is especially
ugly though not very large for 'inline'.  There are similar macros for
__inline and __inline__.  Plain inline has only been standard for 15 years
now.  __inline is gcc's 20+ year old workaround for inline not being
standard.  __inline__ is an alternative spelling of this.  Its use is
just a style bug.  All of these are assumed to exist if the compiler is
gcc or __INTEL_COMPILER.  The ifdefs are not messy enough to be correct
even for gcc, since 25+ year old gcc didn't support inlining.  Only a
few places actually uses the __CC_SUPPORTS_*INLINE feature tests, so these
are worse than useless.  Many places use __inline instead of inline, so
they don't depend on the compiler supporting C99 inline or being gcc with
support for inline not killed using -std=c89, etc.

Putting a break after a noreturn function makes the code less readable and will 
cause errors in non-buggy static analysers (dead code warning - why do you have 
a break on an unreachable line?).

Similarly for lint comments like /* NOTREACHED */.  Even lint shouldn't need
help to know that standard functions like exit() don't return.

Bruce
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Reply via email to