Re: Raising our compiler requirements for 9.6

On Wed, Jul 1, 2015 at 6:24 PM, Andres Freund <andres@anarazel.de> wrote:
> On 2015-07-02 00:15:14 +0200, Andres Freund wrote:
>> animal       OS              compiler                 inline   quiet inline     varargs
>
>> brolga       cygwin          gcc-4.3                  y        y
>
> 4.3 obviously supports varargs. Human error.
>
>> pademelon    HP-UX 10.2      HP C Compiler 10.32      n        n                n
>
> Since, buildfarm/quiet inline test issues aside, pademelon is the only
> animal not supporting inlines and varargs, I think we should just go
> ahead and start to use both.

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.

In the case of static inline, the main problem with the status quo
AFAICS is that you have to do a little dance any time you'd otherwise
use a static inline function (for those following along at home, "git
grep INCLUDE_DEFINITIONS src/include" to see how this is done).  Now,
it is obviously the case that the first time somebody has to do this
dance, they will be somewhat inconvenienced, but once you know how to
do it, it's not incredibly complicated.  So, just to play the devil's
advocate here, who really cares?  The way we're doing it right now
works everywhere and is as efficient on each platform as the compiler
on that platform can support.  I accept that there is some developer
convenience to not having to worry about the INCLUDE_DEFINITIONS
thing, and maybe that's a sufficient reason to do it, but is that the
only benefit we're hoping to get?

I'd consider an argument for adopting one of these features to be much
stronger if were accompanied by arguments like:

- If we require feature X, we can reduce the size of the generated
code and improve performance.
- If we require feature X, we can reduce the risk of bugs.
- If we require feature X, static analyzers will be able to understand
our code better.

If everybody else here says "working around the lack of feature X is
too much of a pain in the butt and we want to adopt it purely too make
development easier", I'm not going to sit here and try to fight the
tide.  But I personally don't find such arguments all that exciting.
It's not at all clear to me that static inline or variadic macros
would make our lives meaningfully better, and like Peter, I think //
comments are a not something we should adopt, because one style is
better than two.  Designated initializers would have meaningful
documentation value and might help to decrease the risk of bugs, so
that almost seems more interesting to me than static inline.  We'd
need to check what pgindent thinks of them, though, and how much
platform coverage we'd be surrendering.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company