Date: Fri, 11 May 2007 17:25:16 -0400 From: David Schultz <das@FreeBSD.ORG> To: Maciej Sobczak <prog@msobczak.com> Cc: freebsd-standards@FreeBSD.ORG Subject: Re: Conventions for system headers Message-ID: <20070511212516.GA32555@VARK.MIT.EDU> In-Reply-To: <464378FE.1010503@msobczak.com> References: <463C63F1.6050204@msobczak.com> <20070506204102.GA31204@VARK.MIT.EDU> <463ECD36.8020701@msobczak.com> <20070507200241.V48720@besplex.bde.org> <464378FE.1010503@msobczak.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070511212516.GA32555>