Re: Unportable coding in reorderbuffer.h

On 2014-03-05 20:03:16 -0500, Tom Lane wrote:
> However, this is probably a bit beside the point. I'm quite prepared
> to believe that nobody uses gcc < 4.0 anymore. The question is what
> older non-gcc compilers are still out there, and can we either get hold
> of them for the buildfarm, or trust that a really old gcc will complain
> about the same things they would? I suspect that most of the candidates
> would be proprietary compilers, so short of shelling out license fees
> I think we might be stuck with using old gcc as a proxy.

I wonder if it makes sense to send out an -announce email asking for
critters if they want $platform to stay supported. No response doesn't
imply explicitly desupporting $platform...
The channels where I recall request for critters on old platforms being
made don't have a very high circulation (e.g. -bugs).

> > I personally think it's time to dump some older compiler versions, and
> > adopt at least individual C99 features (e.g. static inlines).
>
> Meh. In the first place, what you want is not C99 inlines it's GNU
> inlines; the standard's version is brain-dead.

That's true for several inline variants (extern inline, inline without
extern), but unless I am severely misremembering not for static
inlines. And static inline is what I am interested in.

> But I'm not prepared to declare us a GCC-only shop.

All platforms, even the hpux critter that existed till some time ago, do
support static inline. It's only that the hpux critter warned about unused
functions, but even that could have been disabled with a compiler flag.

> In the second place, we already have a
> workable if slightly klugy solution for GNU inlines without assuming
> all compilers do that.

Meh squared.

As the person first starting with the STATIC_IF_INLINE thing I am
readily declaring it a utterly horrible crock. And not one suited for
all things.
I very much want to replace some of the uglier macros with inline
functions. Some are very, very hard to understand and give utterly
horrible error messages that are very hard to understand, even for
experienced people. And several of those cannot be replaced by a extern
function without indirectly making the respective
non-static-inline-supporting platforms indirectly unsupported.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services