Re: Raising our compiler requirements for 9.6

Peter Geoghegan <pg(at)heroku(dot)com> writes:
> On Wed, Jul 1, 2015 at 9:14 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> The list of features, in the order of perceived importance, that might
>> be worthwhile thinking about are:
>> * static inline
>> * variadic macros
>> * designated initializers (e.g. somestruct foo = { .bar = 3 } )
>> * // style comments (I don't care, but it comes up often enough ...)

> I don't want to add // style comments, FWIW.

I concur with that one. I think the portability risk is nil (even
pademelon's compiler takes // without complaint, which surprised me
when I realized it). Rather, I think the argument for continuing to
disallow // has to do with maintaining code style consistency. A mishmash
of // and /* comments looks like heck. (Note, BTW, that pgindent will
forcibly convert // to /* in some though seemingly not all cases.)

As far as "static inline" goes, it occurs to me after more thought that
there really is zero risk of build failures if we start relying on that,
because we already have the "#define inline as empty" trick in configure.
What would happen, on a compiler like pademelon's, is that you'd get a
whole lot of warnings about unreferenced static functions. And maybe some
bloat in the executable, if the compiler is not smart enough to drop those
functions from its output. I think both of these effects are probably
acceptable considering what a small minority of platforms would have any
issue.

A potentially larger issue is that I think we have places where frontend
code is #include'ing backend headers that contain macros we might wish
to convert to inline functions, and that will not work if the macros
contain references to backend functions or global variables. But we could
solve that by refactoring headers where necessary.

> What is the state of support like for variadic macros and designated
> initializers? Unlike static inline, I am not aware that they are
> something that was widely implemented before C99 was formalized.

I agree that the value-for-portability-risk tradeoff doesn't look
great for these features.

regards, tom lane