Re: Missing include in sys/ipc.h
On Thu, Nov 13, 2014 at 10:31 PM, Brad Smith b...@comstyle.com wrote: ping. Discussion died out. Can we please move this issue forward? It's in Philip
Re: Missing include in sys/ipc.h
On 09/20/14 15:34, Philip Guenther wrote: On Sat, Sep 20, 2014 at 11:28 AM, Mark Kettenis mark.kette...@xs4all.nl wrote: Date: Sat, 20 Sep 2014 18:15:31 + 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. ping. Discussion died out. Can we please move this issue forward? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Missing include in sys/ipc.h
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 + 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.
Re: Missing include in sys/ipc.h
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.
Re: Missing include in sys/ipc.h
Date: Sat, 20 Sep 2014 18:15:31 + 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.
Re: Missing include in sys/ipc.h
Oh, looks like man pages should be fixed too. There is no mention in POSIX 2008 that sys/types.h and sys/ipc.h should be included: http://pubs.opengroup.org/onlinepubs/9699919799/functions/shmctl.html http://pubs.opengroup.org/onlinepubs/9699919799/functions/shmget.html http://pubs.opengroup.org/onlinepubs/9699919799/functions/shmat.html So this means that current behavior is not exactly what POSIX 2008 says.
Re: Missing include in sys/ipc.h
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. Good point, I didn't notice that, I was just testing sys/shm.h based on what POSIX 2008 specification says and detected that this isn't working as it should.
Re: Missing include in sys/ipc.h
On Sat, Sep 20, 2014 at 11:28 AM, Mark Kettenis mark.kette...@xs4all.nl wrote: Date: Sat, 20 Sep 2014 18:15:31 + 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. Philip Guenther
