linux-kernel - Re: [PATCH] MIPS: Make BUG() _

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.1.10.0811211059290.20023@ftp.linux-mips.org>
Date:	Fri, 21 Nov 2008 11:14:30 +0000 (GMT)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	David Daney <ddaney@...iumnetworks.com>,
	linux-mips <linux-mips@...ux-mips.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] MIPS: Make BUG() __noreturn.

On Fri, 21 Nov 2008, Geert Uytterhoeven wrote:

> > That sounds like your __noreturn macro is wrong.
> > 
> > Try using __attribute__ ((__noreturn__))
> > 
> > if that works then fix up the __noreturn definitions for the MIPS and gcc
> > you have.
> 
> Nope, gcc is too smart:
> 
> $ cat a.c
> 
> int f(void) __attribute__((__noreturn__));
> 
> int f(void)
> {
> }
> 
> $ gcc -c -Wall a.c
> a.c: In function f:
> a.c:6: warning: `noreturn' function does return
> $ 

 Hmm, in the case of your example the warning is justified, because the 
(virtual) "return" statement of your function is in a unconditional block.  
Otherwise it looks like the attribute is useless -- it looks like it can 
only be used for functions where GCC can determine the function does not 
return anyway.  Which means it is redundant.

 The cases where within the function concerned there is a volatile asm or 
a conditional block which cannot be determined with simple static analysis 
that it does stop look like legitimate ones for the use of the "noreturn" 
attribute and my opinion is GCC should not warn about them with -Wall, 
though a separate -W<whatever> option for the inquisitive would make sense 
to me.  It might be worthwhile to have a look into archives of the GCC 
mailing lists to see how the implementation has evolved into the current 
form and if no useful conclusion can be made, to bring the issue now 
and/or file a bug report.

  Maciej
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/