> Date: Sat, 20 Sep 2014 12:34:42 -0700 > From: Philip Guenther <guent...@gmail.com> > > On Sat, Sep 20, 2014 at 11:28 AM, Mark Kettenis <mark.kette...@xs4all.nl> > wrote: > >> Date: Sat, 20 Sep 2014 18:15:31 +0000 > >> From: Miod Vallat <m...@online.fr> > >> > >> > shmctl(2)/shmget(2)/shmat(2) all document > >> > > >> > #include <sys/types.h> > >> > #include <sys/ipc.h> > >> > #include <sys/shm.h> > >> > > >> > as a requirement for calling these functions. > >> > >> That was my first thought, but according to > >> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_ipc.h.html > >> ``The <sys/ipc.h> header shall define the uid_t, gid_t, mode_t and key_t > >> types as described in <sys/types.h>'', which is currently not the case. > > > > Unfortunately it doesn't allow us to make everything in <sys/types.h> > > available though. So simply including <sys/types.h> from <sys/ipc.h> > > isn't the right solution. > > No, it does permit us to just #include <sys/types.h>, because POSIX > reserves the *_t namespace in all its headers, and that's all that > <sys/types.h> exports. We've tried to do more minimal > #including/exporting generally, but SysV IPC is enough of a corner > that just pulling in <sys/types.h> from <sys/ipc.h> is fine by me.
Well, in various places the standard says something like Inclusion of the <foo.h> header may make visible symbols defined in <bar.h>. I've always interpreted this as saying that including another header file is not ok unless specifically permitted. It used to say that about <sys/types.h> in several places. But for some reason this changed between the 2004 and 2013 editions. For example: Inclusion of the <aio.h> header may make visible symbols defined in the headers <fcntl.h>, <signal.h>, <sys/types.h>, and <time.h>. to Inclusion of the <aio.h> header may make visible symbols defined in the headers <fcntl.h>, <signal.h>, and <time.h>.
