Re: pid_t data type
- From: David Schwartz <davids@xxxxxxxxxxxxx>
- Date: Wed, 19 Mar 2008 06:08:33 -0700 (PDT)
On Mar 18, 12:09 pm, "jason.cipri...@xxxxxxxxx"
<jason.cipri...@xxxxxxxxx> wrote:
"The implementation shall support one or more programming environments
in which the widths of blksize_t, pid_t, size_t, ssize_t, suseconds_t,
and useconds_t are no greater than the width of type long."
If you take that to mean that *all* supported "programming
environments" have pid_t with width no greater than the width of type
long, then it *is* save to store pid_t's in a long. Is there something
that indicates that it's not?
That's definitely not what it says. It says such an environment must
be supported, not that it must be the only one supported or that it
must be the default. Storing a pid_t in a long may limit which
environments you can use.
If that's the case the only two issues with using long instead of
pid_t are:
1) If that standard changes some day, and
2) Using pid_t clearly indicates that the variable, function
parameter, etc., is meant to hold a process ID, and not some arbitrary
integer with another meaning. Saves on documentation.
What about cases where you need a pointer to something that holds a
pid, like posix_spawn? What about cases where you need to pass a PID
through a function with a '...' definition?
DS
.
- References:
- pid_t data type
- From: Sanchit
- Re: pid_t data type
- From: Logan Shaw
- Re: pid_t data type
- From: Rainer Weikusat
- Re: pid_t data type
- From: Sanchit
- Re: pid_t data type
- From: Gordon Burditt
- Re: pid_t data type
- From: Rainer Weikusat
- Re: pid_t data type
- From: jason.cipriani@xxxxxxxxx
- Re: pid_t data type
- From: Rainer Weikusat
- Re: pid_t data type
- From: jason.cipriani@xxxxxxxxx
- pid_t data type
- Prev by Date: Re: pid_t data type
- Next by Date: Re: Sessions and groups
- Previous by thread: Re: pid_t data type
- Next by thread: Re: pid_t data type
- Index(es):
Relevant Pages
|