linux-kernel - Re: any value to "NORET

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]

Date:	Fri, 25 May 2007 00:23:39 +0530
From:	"Satyam Sharma" <satyam.sharma@...il.com>
To:	"Robert P. J. Day" <rpjday@...dspring.com>
Cc:	"Krzysztof Halasa" <khc@...waw.pl>, "Adrian Bunk" <bunk@...sta.de>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: any value to "NORET_TYPE" macro?

On 5/24/07, Robert P. J. Day <rpjday@...dspring.com> wrote:
> On Wed, 23 May 2007, Satyam Sharma wrote:
>
> > Actually there's another thing :-) The __attribute__((xxx)) must go
> > with the function _declarations_ (and not the
> > implementations/definitions).
>
> that's not true, AFAICT.  the pattern seems to be that, in the case of
> declarations, attributes go at the end, as in:
>
> arch/sparc/boot/btfixupprep.c:void fatal(void) __attribute__((noreturn));

Yes, please, this is the normal way.

> while in actual definitions, they typically go after the return type,
> as in arch/arm/kernel/traps.c:
>
> void __attribute__((noreturn)) __bug(const char *file, int line)
> {
>         printk(KERN_CRIT"kernel BUG at %s:%d!\n", file, line);
>         *(int *)0 = 0;
>
>         /* Avoid "noreturn function does return" */
>         for (;;);
> }

Function attributes don't need to appear in function definitions at all.
(I've not come across such cases often, so this is certainly not the
standard). Anyway, the above is a case that the function lacks a
separate declaration which is why we put it there at the definition.
And yes, if we really do have to put an attribute in the function
definition, then we do need to place it _before_ the function name.

>   is that the standard that most people use?  if it is, i can use that
> standard for the cleanup.

Ok, so if you're really planning to do this cleanup, you can do the
following (for all occurrences of NORET_TYPE):

1. If this is a function _declaration_ (i.e. a prototype in some
header or some .c file), then remove the NORET_TYPE macro. Also,
if an ATTRIB_NORET or NORET_AND already exists then you're done.
Else, introduce an ATTRIB_NORET after the arglist but before ;

2. If this is a function _definition_, then remove the NORET_TYPE
macro.
	(a) If a _declaration_ also exists somewhere (say, some
	    header or in the same .c file) for this function, then go
	    and check it.
		(i) If it already contains an ATTRIB_NORET or
		    NORET_AND, then you're done.
		(ii) Else, introduce ATTRIB_NORET.

	(b) If no separate declaration exists for this function,
	    then just introduce the ATTRIB_NORET _before_ the
	    function name if it isn't there already.

I suspect the above would cover all cases :-)
-
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/