Re: Add unistd.h to c.h - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Add unistd.h to c.h
Date
Msg-id 29118.1299881407@sss.pgh.pa.us
Whole thread Raw
In response to Re: Add unistd.h to c.h  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> On 11.03.2011 18:55, Bruce Momjian wrote:
>> OK, I am just asking.  FYI, we already include a boatload of includes in
>> c.h:
>> 
>> #include<stdio.h>
>> #include<stdlib.h>
>> #include<string.h>
>> #include<stddef.h>
>> #include<stdarg.h>
>> #ifdef HAVE_STRINGS_H
>> #include<strings.h>
>> #endif
>> #ifdef HAVE_STDINT_H
>> #include<stdint.h>
>> #endif
>> #include<sys/types.h>

> Presumably all of these are used by something in c.h itself. At least 
> strings.h is needed by memset, and stddef.h and/or stdlib.h is needed 
> for size_t. I'm too lazy to check the rest, but if there are any header 
> files there that are not in fact used by anything in c.h itself, they 
> should be removed from c.h, rather than going further into that direction.

I would argue that most of those includes (in particular all the stdXXX
ones) are needed to establish a minimum sane C programming environment.
Removing them would not be productive, regardless of whether c.h itself
requires them.

There are a bunch of *other* includes in c.h and the OS-specific port
files, which I'd like to see minimized, but not those.  It's this kind
of thing that we should be trying to get rid of:

#if defined(WIN32) || defined(__CYGWIN__)
#include <fcntl.h>            /* ensure O_BINARY is available */
#endif

because it greatly increases the probability that a patch developed on
one platform will not port to others where c.h doesn't pull in the
same header.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: FuncExpr.collid/OpExpr.collid unworkably serving double duty
Next
From: David Fetter
Date:
Subject: Re: pg_dump -X