This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Can pid_t be a long?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]