#include sys/types.h in sys/mman.h
Christopher Zimmermann wrote on misc@, Wed, Feb 24, 2010 at 08:53:28PM +0100: I just got some errors while trying to compile ptlib: error: type specifier omitted for parameter `size_t' [...] They resulted from size_t not being defined in sys/mmap.h I guess you are talking about sys/mman.h. I could fix this problem by including sys/types.h instead of sys/cdefs.h in sys/mmap.h I don't understand why sys/cdefs.h might be needed in sys/types.h, but i don't feel qualified to propose its removal either. Maybe it is needed for something. Is this a problem of ptlib, which should not directly include mmap.h or should this possibly be fixed in OpenBSD? In OpenBSD, we usually include headers in other headers if that is required by a relevant standard, in particular by POSIX. Now, sys/mman.h is specified by POSIX, and it says: The sys/mman.h header shall define the mode_t, off_t, and size_t types as described in sys/types.h. Thus, I do think you have a point, and sys/types.h is indeed missing from sys/mman.h and should be added. I won't touch this stuff though without very clear OKs from the right people, in particular around this time of the year. Index: mman.h === RCS file: /cvs/src/sys/sys/mman.h,v retrieving revision 1.18 diff -u -r1.18 mman.h --- mman.h 21 Jul 2003 22:52:19 - 1.18 +++ mman.h 24 Feb 2010 20:52:56 - @@ -107,6 +107,7 @@ #ifndef _KERNEL #include sys/cdefs.h +#include sys/types.h __BEGIN_DECLS /* Some of these int's should probably be size_t's */
Re: #include sys/types.h in sys/mman.h
On Wednesday 24 February 2010 15:57:43 Ingo Schwarze wrote: In OpenBSD, we usually include headers in other headers if that is required by a relevant standard, in particular by POSIX. I don't know where you get this idea from. Theo has made it pretty clear in the past that what you said above is not true. Read the man pages. No kidding... if you go and include everything everywhere, and then those headers include themselves too, and some of them recurse even deeper, pretty soon you are pushing half a megabyte of stuff into ccp which still has to find the lines which start with #, and do all that extra IO.
Re: #include sys/types.h in sys/mman.h
On Wed, Feb 24, 2010 at 05:38:14PM -0700, Theo de Raadt wrote: On Wednesday 24 February 2010 15:57:43 Ingo Schwarze wrote: In OpenBSD, we usually include headers in other headers if that is required by a relevant standard, in particular by POSIX. I don't know where you get this idea from. Theo has made it pretty clear in the past that what you said above is not true. Read the man pages. No kidding... if you go and include everything everywhere, and then those headers include themselves too, and some of them recurse even deeper, pretty soon you are pushing half a megabyte of stuff into ccp which still has to find the lines which start with #, and do all that extra IO. It might be surprising, but for any semi-modern version of GCC applying the patch and compiling #include sys/types.h #include sys/mman.h doesn't result in significant IO change compared to the unpatched version. The compiler is smart enough to recognise the normal include guard style and won't touch the file again. So please, don't justify breaking POSIX compliant code by reducing IO. That said, sys/types.h is most likely not what is needed to make sys/mman.h self-contained, but that's a completely separate issue. Joerg
Re: #include sys/types.h in sys/mman.h
It might be surprising, but for any semi-modern version of GCC applying the patch and compiling #include sys/types.h #include sys/mman.h doesn't result in significant IO change compared to the unpatched version. The compiler is smart enough to recognise the normal include guard style and won't touch the file again. So please, don't justify breaking POSIX compliant code by reducing IO. That said, sys/types.h is most likely not what is needed to make sys/mman.h self-contained, but that's a completely separate issue. Oh, so we should trust the compiler? I am certain that rule is not written anywhere. sys/mman.h is not required to pull in sys/types.h. Applications which use it, must do that themselves. Guarding should be used where it needs to be used, and nowhere else. Header files should not be pulled in unless the APIs are understood. POSIX has completely undermined itself and turned itself into junk under the guidance of a very small group of people with one platform in mind.
Re: #include sys/types.h in sys/mman.h
That said, sys/types.h is most likely not what is needed to make sys/mman.h self-contained, but that's a completely separate issue. By the way, where is it written that sys/mman.h has to be self-contained? I bet it is written exactly the other way around.
Re: #include sys/types.h in sys/mman.h
On Wed, Feb 24, 2010 at 07:27:27PM -0700, Theo de Raadt wrote: That said, sys/types.h is most likely not what is needed to make sys/mman.h self-contained, but that's a completely separate issue. By the way, where is it written that sys/mman.h has to be self-contained? I bet it is written exactly the other way around. http://www.opengroup.org/onlinepubs/9699919799/ E.g. sys/mman.h is supposed to define size_t. The easiest approach for that is to include sys/types.h, but adding e.g. #ifndef _SIZE_T_DEFINED_ #define _SIZE_T_DEFINED_ typedef __size_tsize_t; #endif is acceptable (and preferable). The goal beside the standalone requirement is to enforce minimal pollution of the application namespace. If a source file needs a symbol from foo.h, it should have to include it, but it shouldn't have to know how the headers work internally. And this is exactly the problem with POSIX. When was that change made? Who was asked about it? How much backwards compatibility did they break? The whole process is run by the same people who refuse to put strlcpy and strlcat into Linux. Unfortunately POSIX is a joke.
Re: #include sys/types.h in sys/mman.h
On Wed, Feb 24, 2010 at 07:56:27PM -0700, Theo de Raadt wrote: http://www.opengroup.org/onlinepubs/9699919799/ And this is exactly the problem with POSIX. When was that change made? It is the same kind of requirement as ISO C99 has for size_t. The primary header for size_t is stddef.h, but a number of other headers are supposed to provide it as well (like stdlib.h) to be standalone. When was it changed? No idea, the same requirement can be found in SUSv2 (aka UNIX98). Who was asked about it? The Austin Group? Whoever else is part of the necessary ISO/IEC committies? How much backwards compatibility did they break? I'm failing to see what compatibility was broken here... The whole process is run by the same people who refuse to put strlcpy and strlcat into Linux. Given that Linux was pretty much irrelevant at the time... Unfortunately POSIX is a joke. No comment. Joerg
