Thread: Add unistd.h to c.h
Twenty percent of our C files include unistd.h. Should we include unistd.h in c.h and remove mentions of unistd.h in files that include c.h? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On 11.03.2011 18:50, Bruce Momjian wrote: > Twenty percent of our C files include unistd.h. Should we include > unistd.h in c.h and remove mentions of unistd.h in files that include > c.h? Why? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
Heikki Linnakangas wrote: > On 11.03.2011 18:50, Bruce Momjian wrote: > > Twenty percent of our C files include unistd.h. Should we include > > unistd.h in c.h and remove mentions of unistd.h in files that include > > c.h? > > Why? Well, that is one less C include file in 151 C files, and just one additional line in c.h. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Fri, Mar 11, 2011 at 11:50 AM, Bruce Momjian <bruce@momjian.us> wrote: > Twenty percent of our C files include unistd.h. Should we include > unistd.h in c.h and remove mentions of unistd.h in files that include > c.h? Why? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 11.03.2011 18:53, Bruce Momjian wrote: > Heikki Linnakangas wrote: >> On 11.03.2011 18:50, Bruce Momjian wrote: >>> Twenty percent of our C files include unistd.h. Should we include >>> unistd.h in c.h and remove mentions of unistd.h in files that include >>> c.h? >> >> Why? > > Well, that is one less C include file in 151 C files, and just one > additional line in c.h. It would make 80% of C files include unistd.h unnecessarily, slowing down compilation by some small margin. -1 -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
Heikki Linnakangas wrote: > On 11.03.2011 18:53, Bruce Momjian wrote: > > Heikki Linnakangas wrote: > >> On 11.03.2011 18:50, Bruce Momjian wrote: > >>> Twenty percent of our C files include unistd.h. Should we include > >>> unistd.h in c.h and remove mentions of unistd.h in files that include > >>> c.h? > >> > >> Why? > > > > Well, that is one less C include file in 151 C files, and just one > > additional line in c.h. > > It would make 80% of C files include unistd.h unnecessarily, slowing > down compilation by some small margin. > > -1 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> -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Fri, Mar 11, 2011 at 11:53 AM, Bruce Momjian <bruce@momjian.us> wrote: > Heikki Linnakangas wrote: >> On 11.03.2011 18:50, Bruce Momjian wrote: >> > Twenty percent of our C files include unistd.h. Should we include >> > unistd.h in c.h and remove mentions of unistd.h in files that include >> > c.h? >> >> Why? > > Well, that is one less C include file in 151 C files, and just one > additional line in c.h. We could take it a little further and just make c.h include everything that any file needs anywhere in the system. That would save even more lines of code, but it has nothing else to recommend it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
Excerpts from Heikki Linnakangas's message of vie mar 11 13:59:59 -0300 2011: > 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. Yeah. FWIW I sometimes make efforts to reduce the reach of headers, for example by removing them from other headers that don't need them. It is quite the opposite to what you propose here. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
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