Re: [HACKERS] Candidate for local inline function? - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: [HACKERS] Candidate for local inline function?
Date
Msg-id CACjxUsOQaevdMmm9tB9i8MMGt75i8+X6SZTJBTjUUVo_xL4mDw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Candidate for local inline function?  (Andres Freund <andres@anarazel.de>)
Responses Re: Candidate for local inline function?  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Fri, Mar 17, 2017 at 3:23 PM, Andres Freund <andres@anarazel.de> wrote:
> On 2017-03-17 15:17:33 -0500, Kevin Grittner wrote:
>> Why do we warn of a hazard here instead of eliminating said hazard
>> with a static inline function declaration in executor.h?
>
> Presumably because it was written long before we started relying on
> inline functions :/

Right.  git blame says it was changed in 2004.

>> /*
>>  * ExecEvalExpr was formerly a function containing a switch statement;
>>  * now it's just a macro invoking the function pointed to by an ExprState
>>  * node.  Beware of double evaluation of the ExprState argument!
>>  */
>> #define ExecEvalExpr(expr, econtext, isNull) \
>>     ((*(expr)->evalfunc) (expr, econtext, isNull))
>>
>> Should I change that to a static inline function doing exactly what
>> the macro does?  In the absence of multiple evaluations of a
>> parameter with side effects, modern versions of gcc have generated
>> the same code for a macro versus a static inline function, at least
>> in the cases I checked.
>
> I'm absolutely not against changing this to an inline function, but I'd
> prefer if that code weren't touched quite right now, there's a large
> pending patch of mine in the area.  If you don't mind, I'll just include
> the change there, rather than have a conflict?

Fine with me.

-- 
Kevin Grittner



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] Candidate for local inline function?
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Candidate for local inline function?