Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> We can certainly move our header inclusion order around, but that is
>> simply an application-level workaround for a broken system header.
> I didn't think so. I always thought there were requirements in include
> ordering.
There are certain broken OSes that think it's okay to let applications
deal with that, but they are certainly broken. What is an application
supposed to do if two different implementations have conflicting
requirements for header include order? Why should it be an
application's responsibility to worry about it in the first place?
I don't even know of any place where it could be documented that
"<foo.h> requires <bar.h> to be included first" in the standard man
page layout, because there isn't a man page per header file. And I'll
definitely bet lunch that that FreeBSD developer didn't fix the man
pages to say any such thing when he made that typedef change ;-)
If all versions of Unix had identical system headers then this sort
of thing wouldn't be a big deal, but since they don't, "each header
can be included independently" is the only reasonable approach.
We have a number of workarounds of this kind in Postgres already,
and I don't doubt that this one will not be the last one. But that
does not persuade me that system headers with this sort of problem
are acceptable. In this case we have an opportunity to complain,
and we should.
regards, tom lane