Date: Fri, 30 Nov 2012 10:30:25 +0100 From: Erik Cederstrand <erik@cederstrand.dk> To: Konstantin Belousov <kostikbel@gmail.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Eitan Adler <eadler@freebsd.org> Subject: Re: svn commit: r243665 - head/sbin/dump Message-ID: <9E5035D8-506F-4A18-9511-BFA0511ACE10@cederstrand.dk> In-Reply-To: <20121129120147.GE3013@kib.kiev.ua> References: <201211290516.qAT5GoT5098709@svn.freebsd.org> <20121129120147.GE3013@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Den 29/11/2012 kl. 13.01 skrev Konstantin Belousov <kostikbel@gmail.com>: > On Thu, Nov 29, 2012 at 05:16:50AM +0000, Eitan Adler wrote: >> Author: eadler >> Date: Thu Nov 29 05:16:50 2012 >> New Revision: 243665 >> URL: http://svnweb.freebsd.org/changeset/base/243665 >> >> Log: >> Mark non-returning function as such >> >> PR: bin/172978 >> Approved by: cperciva >> MFC after: 3 days >> >> Modified: >> head/sbin/dump/dump.h >> >> Modified: head/sbin/dump/dump.h >> ============================================================================== >> --- head/sbin/dump/dump.h Thu Nov 29 03:48:39 2012 (r243664) >> +++ head/sbin/dump/dump.h Thu Nov 29 05:16:50 2012 (r243665) >> @@ -121,7 +121,7 @@ void trewind(void); >> void writerec(char *dp, int isspcl); >> >> void Exit(int status) __dead2; >> -void dumpabort(int signo); >> +void dumpabort(int signo) __dead2; >> void dump_getfstab(void); >> >> char *rawname(char *cp); > What is the goal of this change ? > > It is arguably backward. There is absolutely no use to mark signal handler > as __dead2, and all other uses do not benefit from the redundand declaration. I submitted this patch because it fixes static analysis warnings. Compilation units that contain the header but not the implementation need this to reason about the code. As I see it, the __dead2 is part of the function definition, just like 'void' and 'int signo'. Actually, before the patch, return type 'void' was a lie, because the function never returns. > Also, being quite removed from the function definition, there is a chance > that some future modification would make the attribute a lie. That is not any different than some future modification changing the return type to 'int', which the compiler would also warn about. Thanks, Erik
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9E5035D8-506F-4A18-9511-BFA0511ACE10>