Re: [HACKERS] Candidate for local inline function?
От | Kevin Grittner |
---|---|
Тема | Re: [HACKERS] Candidate for local inline function? |
Дата | |
Msg-id | CACjxUsOQaevdMmm9tB9i8MMGt75i8+X6SZTJBTjUUVo_xL4mDw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Candidate for local inline function? (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Candidate for local inline function?
|
Список | 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 по дате отправления: