From mboxrd@z Thu Jan  1 00:00:00 1970
From: bjorn@mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Wed, 11 Mar 2015 20:41:55 +0100
Subject: confusing code....whats the point of this construct ?
In-Reply-To: <10256.1426100251@turing-police.cc.vt.edu> (Valdis Kletnieks's
	message of "Wed, 11 Mar 2015 14:57:31 -0400")
References: <20150311141744.GC23845@opentech.at>
	<55475.1426084817@turing-police.cc.vt.edu>
	<87twxr4llm.fsf@nemi.mork.no> <20150311164656.GA22024@opentech.at>
	<66204.1426093213@turing-police.cc.vt.edu>
	<4E5779AD88B2F040B8A7E83ECF544D1A5C5E09@SJCPEX01CL03.citrite.net>
	<10256.1426100251@turing-police.cc.vt.edu>
Message-ID: <87a8zj48zg.fsf@nemi.mork.no>
To: kernelnewbies@lists.kernelnewbies.org
List-Id: kernelnewbies.lists.kernelnewbies.org

Valdis.Kletnieks at vt.edu writes:
> On Wed, 11 Mar 2015 18:37:32 -0000, Jeff Haran said:
>
>> I don't understand the problem here. The caller passes in a condition to be
>> evaluated in a loop. Many times that condition is quite simple (e.g. a counter
>> being non-zero). If it was a function the caller would have to pass in a
>> pointer to a function that does the evaluation, as in:
>
> We do pointers to callback functions all the time.  We try *really* hard
> to avoid anonymous lambda functions (which is basically what we have here).
>
> The problem here is that there's about 3 zillion ways to screw up the inline
> version, starting with the compiler optimizing the control variable into a
> hoisted load outside the loop and causing the test to always fail - note that
> the macro does *not* use any barriers or volatile or anything like that.

We could go a couple of more rounds on this, but I don't think there is
much point.  It is sufficent to note that there are different views on
the subject.  None of them are "right" or "wrong". Use a function if you
like. There are probably 3 zillion ways to screw up either way :-)


Bj?rn