Andres Freund <and...@2ndquadrant.com> writes: > On 2014-03-05 17:40:56 -0500, Tom Lane wrote: >> By the time you get done fixing the portability issue, I suspect you >> won't have a union at all for the first case.
> You might be right. I'd rather not leak the internal enum values to the > public though, so there are two choices: > * define as enum, but store values in the that aren't actually valid > members. IIRC that's legal, even if not pretty. Anything outside > reorderbuffer.c doesn't ever see the values that aren't enum values. > * define it as an int, but suggest casting to the enum inside switch() > in examples/docs. Meh. I think you're being *way* too cute here. I'd just put all the values in one enum declaration, and use comments and/or naming convention to mark some of them as internal and not meant to be used outside the reorderbuffer stuff. That will for one thing allow gdb to print all the values properly. And somebody who's bound and determined to violate the abstraction could do it anyway, no? >> What drew my attention to it was an older gcc version complaining >> thusly: [errors] > And there I was, suprised it hadn't turned the buildfarm red. I'm surprised too; I had thought we still had some critters running hoary compilers. We need to do something about that if we actually believe in C90-compiler support. I experimented a little bit and found that modern gcc with -ansi (aka -std=c89) will complain about this particular issue, and it also complains about // comments which are a perpetual hazard; but it is still happy about a lot of other not-C90 things like flexible array members. We could try spinning up a buildfarm critter with -ansi -pedantic but I'm not sure if that's much better. The GCC man page warns that these options are not meant to be a strict check for C90 standard compliance, and anyway the important question is not whether gcc with options that nobody uses will take our code, its whether old compilers that are still in real use will take it. For a long time I was using gcc 2.95.3 on my HPPA dinosaur as a reference for hoary-compiler behavior. That machine is now flaky enough that I don't want to keep it turned on 24/7, but maybe I could compile up 2.95.3 on some other box and start a buildfarm critter. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers