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: Florian Weimer <fweimer at redhat dot com>
- To: Michael Kerrisk <mtk dot manpages at gmail dot com>
- Cc: libc-help <libc-help at sourceware dot org>
- Date: Mon, 12 Oct 2015 13:41:20 +0200
- Subject: Re: Can pid_t be a long?
- Authentication-results: sourceware.org; auth=none
- References: <56165C02 dot 40009 at redhat dot com> <CALxWeYp3Xk37UskA_tgLrG4i2MD-sw02z=p6cSRQ7vBS1=Zrkw at mail dot gmail dot com>
On 10/09/2015 02:26 PM, Michael Kerrisk wrote:
> 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
Thanks, this does indeed help. So making pid_t a long type is not
trivial on architectures where sizeof (int) and sizeof (long) differ.
Florian