Re: Raising our compiler requirements for 9.6 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Raising our compiler requirements for 9.6
Date
Msg-id 26813.1435853415@sss.pgh.pa.us
Whole thread Raw
In response to Re: Raising our compiler requirements for 9.6  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Raising our compiler requirements for 9.6  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> So far this thread is all about the costs of desupporting compilers
> that don't have these features, and you're making a good argument
> (that I think we all agree with) that the cost is small.  But you
> haven't really said what the benefits are.

I made the same remark with respect to varargs macros, and I continue
to think that the cost-benefit ratio there is pretty marginal.

However, I do think that there's a case to be made for adopting static
inline.  The INCLUDE_DEFINITIONS dance is very inconvenient, so it
discourages people from using static inlines over macros, even in cases
where the macro approach is pretty evil (usually, because of multiple-
evaluation hazards).  If we allowed static inlines then we could work
towards having a safer coding standard along the lines of "thou shalt
not write macros that evaluate their arguments more than once".
So the benefits here are easier development and less risk of bugs.
On the other side of the ledger, the costs are pretty minimal; we will
not actually break any platforms, at worst we'll make them unpleasant
to develop on because of lots of warning messages.  We have some platforms
like that already, and it's not been a huge problem.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Raising our compiler requirements for 9.6
Next
From: Peter Eisentraut
Date:
Subject: Re: [PATCH] Reload SSL certificates on SIGHUP