Thread: compile error of PostgreSQL 7.2 on FreeBSD-current

How about including <sys/types.h> before including
<grp.h> in src/backend/utils/init/findbe.c?

I've just compiled 7.2 on FreeBSD-current, which has failed
with compilation error because the type of gr_gid in struct group
is gid_t on FreeBSD-current.

cheers,

hiro hanai

On Fri, 8 Feb 2002, Bruce Momjianwrote:
> > How about including <sys/types.h> before including
> > <grp.h> in src/backend/utils/init/findbe.c?
> > 
> > I've just compiled 7.2 on FreeBSD-current, which has failed
> > with compilation error because the type of gr_gid in struct group
> > is gid_t on FreeBSD-current.
> 
> sys/types.h include is in 7.2.  Please upgrade.

Bruce, I know sys/types include is in 7.2.
I'm talking about the order to include header files.
src/backend/utils/init/findbe.c in 7.2 includes <grp.h>
*before* <sys/types.h>.
But, the type of gr_gid in struct group, which is defined
in <grp.h>, is gid_t. So, <sys/types> should be inclueded
before <grp.h>

The type of gr_gid in <grp.h> was `int' before 22th Jan 2002.
It has been changed as gid_t by Mark Murray on 22th Jan 2002.

Regards,

hiro hanai

hiroyuki hanai <hanai@imgsrc.co.jp> writes:
> But, the type of gr_gid in struct group, which is defined
> in <grp.h>, is gid_t. So, <sys/types> should be inclueded
> before <grp.h>

> The type of gr_gid in <grp.h> was `int' before 22th Jan 2002.
> It has been changed as gid_t by Mark Murray on 22th Jan 2002.

One would think this is a bug in FreeBSD's <grp.h>.  Shouldn't it be
responsible for including the headers it depends on?

We can certainly move our header inclusion order around, but that is
simply an application-level workaround for a broken system header.
        regards, tom lane

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

Tom Lane writes:

> One would think this is a bug in FreeBSD's <grp.h>.  Shouldn't it be
> responsible for including the headers it depends on?

The standards specify (effectively) that sys/types.h must be included
before grp.h.  This can be considered stupid, but it's not really
FreeBSD's fault.

-- 
Peter Eisentraut   peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:
> The standards specify (effectively) that sys/types.h must be included
> before grp.h.  This can be considered stupid, but it's not really
> FreeBSD's fault.

Possibly I'm spoiled: HPUX gets this right.

I ran the same experiment Bruce mentioned, and found that of 192 headers
in HPUX 10.20's /usr/include directory, all but 24 compiled with no
additional inclusions.  The failing headers were

alarm.h dcnodes.h dmapi.h dumprestor.h dvio.h elog.h eucioctl.h
execargs.h exportent.h fbackup.h hard_reg.h initptr.h lc_core.h
m4_frame.h m4_reg.h pfm.h ppfm.h prot.h sad.h soft_reg.h std_space.h
term.h xds.h xomi.h

which are mostly not standardized headers.

The failure rate was higher in the subdirectories of /usr/include, but
that's not surprising.  A lot of the headers underneath /usr/include/sys
don't look like they're even intended to be compiled in userland code.
        regards, tom lane