On Sun, Sep 21, 2014 at 16:20, Mark Kettenis wrote: >> 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>.
If we're going to read semantic tea leaves, this clarification may be because types.h doesn't export anything that you're not always allowed to export. i.e., the warning is redundant, unlike the ones about signal.h.
