This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Can pid_t be a long?
- From: Michael Kerrisk <mtk dot manpages at gmail dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: libc-help <libc-help at sourceware dot org>
- Date: Fri, 9 Oct 2015 14:26:43 +0200
- Subject: Re: Can pid_t be a long?
- Authentication-results: sourceware.org; auth=none
- References: <56165C02 dot 40009 at redhat dot com>
Hi Florian,
On Thu, Oct 8, 2015 at 2:05 PM, Florian Weimer <fweimer@redhat.com> wrote:
> Are there any interfaces which would conflict with a pid_t type which is
> a long? I found just one place:
>
> signalfd_siginfo.ssi_pid is an uint32_t.
>
> Are there any others?
I'm pretty sure perf_event_open() also has similar warts. Look for "pid" in
http://man7.org/linux/man-pages/man2/perf_event_open.2.html
(And for that matter note that kernel thread IDs are also u32 it
various places tehre.)
I don't know of other cases, but I would not be surprised if there
were more... checking...
Hmm, the V3 process accounting record format is similar:
http://man7.org/linux/man-pages/man5/acct.5.html
Likewise the structured data that can be read(2) from an fanotify file
descriptor. See
http://man7.org/linux/man-pages/man7/fanotify.7.html
> To be clear, I'm not wanting to change pid_t for an existing
> architecture, I want to discover if there are constraints on future
> definitions of pid_t.
I hope the above helps.
Cheers,
Michael