svn commit: r287217 - head/usr.sbin/syslogd

[Jilles Tjoelker]

On Sun, Aug 30, 2015 at 11:53:00AM +0200, Ed Schouten wrote:
> 2015-08-28 16:38 GMT+02:00 Joerg Sonnenberger <joerg at britannica.bec.de>:
> > But the compiler can't tell if it is the *intention* that the function
> > never returns. The warning behavior exists because that can easily
> > change with macros etc.

> I think it's important to keep in mind what this keyword was designed for.

> The idea behind this attribute (and the C11 _Noreturn keyword) is to
> allow for propagation of optimisation state across compilation units.
> You use it to annotate functions in header files, so that the compiler
> does not need to handle function return at the call site. This
> knowledge can be automatically be inferred if the function is static.

Although you are right philosophically, in practice there are some
compilers and static analyzers that do benefit from noreturn attributes
on static functions. In particular, gcc 4.2.1 generates better code and
fewer warnings if static functions are annotated with noreturn if
appropriate, and some versions of the Clang/LLVM static analyzer do not
do any cross-procedural analysis at all and depend on noreturn
attributes on static functions to avoid false positives.

> Whether the compiler can throw additional warnings or not based on
> whether this keyword is present or what the intent of the programmer
> is, is completely irrelevant.

In practice this means that many compiler warnings need to be disabled
for the affected compilers.

> I agree with Bruce that this change makes little sense. I would even
> go as far as to say that GCC/Clang should just throw warnings if
> _Noreturn is used on a function that is static or used on a definition
> instead of a declaration.

_Noreturn on a global definition makes no sense but on a static function
it may still be needed.

-- 
Jilles Tjoelker