Conventions for system headers

[David Schultz]

On Thu, May 10, 2007, Maciej Sobczak wrote:
> >>A simple fix, just to keep the convention that allows arbitrary order, 
> >>is to #include Y.h from X.h. This way X.h becomes complete - but the 
> >>namespace pollution does not increase; in fact, the sequence of tokens 
> >>that the compiler sees is exactly the same. It is just more convenient 
> >>for the user and consistent with the standards.
> >
> >It is a bug for standard to allow this
> 
> Why? Can you give some references?
> The C++ standard explicitly allows headers to #include other standard 
> headers. I cannot find anything in the C standard that would forbid it.

C++ is more permissive about this because C++ has namespaces,
which are designed specifically to avoid name conflicts. In C it
causes real problems. People write programs that declare a reference
to their log file as 'FILE *log' and expect it to work as long as
they don't include <math.h>, or they write their own compatibility
shims with the same names as standard interfaces, then expect them
to work so long as they don't include the system header that may
define routines with identical names.

Granted, if, for example, <arpa/inet.h> included <netinet/in.h>
(NB: it doesn't), that wouldn't be too surprising to programmers
or likely to cause conflicts. But it would certainly be bad if
<arpa/inet.h> included <netinet/in.h>, which included <socket.h>,
which included <sys/uio.h>, which declares 'struct iovec'. All of
this is allowed by POSIX, but I've worked on some server software for
a multiplayer game that has its own 'struct iovec', and it would break
if we did things this way. So in general we try to avoid that kind of
thing.

> In any case, POSIX requires that <net/if.h> is complete.
> 
> >>I would like to propose to fix the problem the simple way (for the 
> >>moment) - by just forcibly #include'ing the required headers from 
> >>their dependants. It will not lead to proliferation of new headers and 
> >>the namespace pollution will remain the same as it is now.

You don't necessarily need a proliferation of new headers. Many of
the simple cases (e.g. basic type definitions) can be handled as in
<arpa/inet.h>. If there's anything that can't be fixed in under 3
lines of code, you're welcome to bring it up on this list.