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

From Kevin Grittner
Subject [HACKERS] Candidate for local inline function?
Date
Msg-id CACjxUsNuiXku4=tiN3J-srRNVdS6VPb_-etK0OF3JMhHCbZ-vw@mail.gmail.com
Whole thread Raw
Responses Re: [HACKERS] Candidate for local inline function?  (Andres Freund <andres@anarazel.de>)
Re: [HACKERS] Candidate for local inline function?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Why do we warn of a hazard here instead of eliminating said hazard
with a static inline function declaration in executor.h?

/*
 * 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.

--
Kevin Grittner

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] pageinspect and hash indexes
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] increasing the default WAL segment size