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]

Message-ID: <a781481a0705241012j513957d8vbc993cb395c31158@mail.gmail.com>
Date:	Thu, 24 May 2007 22:42:27 +0530
From:	"Satyam Sharma" <satyam.sharma@...il.com>
To:	"Krzysztof Halasa" <khc@...waw.pl>
Cc:	"Robert P. J. Day" <rpjday@...dspring.com>,
	"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, Krzysztof Halasa <khc@...waw.pl> wrote:
> "Satyam Sharma" <satyam.sharma@...il.com> writes:
>
> > Actually there's another thing :-) The __attribute__((xxx)) must go with the
> > function _declarations_ (and not the implementations/definitions). I noticed
> > after my previous mail that most of the double annotations are actually in
> > the case of the _declarations_ of these non-returning functions, whereas
> > most of the single-occurrences of NORET_TYPE were in the function
> > definitions, which means your patch that simply got rid of NORET_TYPE
> > actually ended up doing exactly the right thing that we wanted :-)
>
> Only half of it. Half of right thing is (here) a bad thing.
>
> NORET_TYPE does not do any harm.
> Removing it removes pointers to attrib((noreturn)) candidates.
> Simple.

NORET_TYPE didn't do any harm because it expanded to /**/. But yes,
removing it does remove the annotations / markers for ATTRIB_NORET
candidates, as I first mentioned to Rday.

But later on going through the code, I noticed that:

1. Most of the combined occurrences of NORET_TYPE along with
ATTRIB_NORET were in function _declarations_. So here, what
we want is to simply remove the NORET_TYPE, and *not* replace
it with ATTRIB_NORET, because it's already there!

2. Most of the single-occurrences (NORET_TYPE alone, without any
ATTRIB_NORET) were in function _implementations_. So here, what
we want is to simply remove the NORET_TYPE, and *not* introduce
any ATTRIB_NORET, because it's not required!

In such a situation, merging a patch that simply gets rid of
NORET_TYPE (i.e. s/NORET_TYPE//) actually ends up doing the
right thing!

... *however* ... as I mentioned next, unfortunately the above 2 points
did not hold for _all_ occurrences of NORET_TYPE. There were
some exceptions (which also I mentioned) where we want to do
somethings slightly more complicated, so I put the ball in Rday's
court -- he had originally expressed a wish to avoid doing complicated
things in this patch.
-
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/