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>
index | next in thread | previous in thread | raw e-mail
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, Erikhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9E5035D8-506F-4A18-9511-BFA0511ACE10>