From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Raising our compiler requirements for 9.6 |
Date: | 2015-07-02 16:10:15 |
Message-ID: | 26813.1435853415@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2015-07-02 16:13:54 | Re: [PATCH] Reload SSL certificates on SIGHUP |
Previous Message | Andres Freund | 2015-07-02 16:01:47 | Re: Raising our compiler requirements for 9.6 |