pid_t data type

pid_t is a data type defines in types.h
but is it realy necessary to use it.. I mean it is a signed integer
type only.. then why should pid_t be used??

Sanchit wrote:

> pid_t is a data type defines in types.h
> but is it realy necessary to use it.. I mean it is a signed integer
> type only..

Perhaps. In any case, what /size/ (or type, if you will) of integer is it?
Is it a short int, an int, a long int, or a long long int?

> then why should pid_t be used??

So that you don't /have/ to know what type of integer the implementation
uses for a pid value.


--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/   | GPG public key available by request
----------      Slackware - Because I know what I'm doing.          ------

On Mar 15, 10:59 pm, Lew Pitcher <lpitc...@teksavvy.com> wrote:
> Sanchit wrote: 
>
> Perhaps. In any case, what /size/ (or type, if you will) of integer is it?
> Is it a short int, an int, a long int, or a long long int?
> 
>
> So that you don't /have/ to know what type of integer the implementation
> uses for a pid value.
>
> --
> Lew Pitcher
>
> Master Codewright & JOAT-in-training | Registered Linux User #112576http:/
/pitcher.digitalfreehold.ca/  | GPG public key available by request
> ----------      Slackware - Because I know what I'm doing.          ------

So if i will use long.. and i am not concerned with memory
management.. will it be fine in every case.. are there any specific
case where we should use only pid_t and not long (any any int type)

In article
<1900a0b6-626c-434c-8660-2c269342d112@d21g2000prf.googlegroups.com>,
Sanchit <sanchitgupta.1@gmail.com> wrote:

> On Mar 15, 10:59 pm, Lew Pitcher <lpitc...@teksavvy.com> wrote: 
>
> So if i will use long.. and i am not concerned with memory
> management.. will it be fine in every case.. are there any specific
> case where we should use only pid_t and not long (any any int type)

It has nothing to do with memory management, it's about calling
sequences.  If your declarations of system calls don't match what the OS
actually uses, the data won't be passed properly when you call them.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***

Sanchit wrote:
> So if i will use long.. and i am not concerned with memory
> management.. will it be fine in every case..

If you use pid_t, it will be fine in every case.  If you use
long, there are no guarantees.  If you use pid_t, you will be
using what the producers of the system have tested.  If you
use long, you will be using something that is unsupported and
untested.

> are there any specific
> case where we should use only pid_t and not long (any any int type)

Yes, any case when you want to store a pid, you should use pid_t.
You might not experience problems with a long instead, but since
you don't know, and since it is just easy to use pid_t and pid_t
provides better documentation and better readability, why would
do it the other way and introduce potential problems for no
benefit?

- Logan

Sanchit wrote:
> On Mar 15, 10:59 pm, Lew Pitcher <lpitc...@teksavvy.com> wrote: 
> [...]
> So if i will use long.. and i am not concerned with memory
> management.. will it be fine in every case.. are there any specific
> case where we should use only pid_t and not long (any any int type)

There is an automobile in my driveway.  To move it
from my driveway onto the public roads, I must have in
my possession a driving license.  My automobile happens
to be a Mazda, but my driving license does not specify
that I am licensed to drive Mazdas; it says I am licensed
to drive passenger automobiles, vans, and light trucks
of any make and model.

There is a process in your system.  To send it a signal,
you must have in your possession a pid_t value that identifies
the target process.  On your system, the pid_t value happens
to be an int, but the API does not specify that you must supply
an int; it says that you must supply whatever the system uses
as a pid_t, whatever type that turns out to be.

My driving license is more flexible and useful because
it is intentionally vague about the types of vehicles I
may drive; there are a few restrictions (no motorcycles,
for example), but by and large I may drive whatever make
of car I like.  The POSIX API gains similar flexibility and
usefulness through similar intentional vagueness about the
nature of pid_t; there are a few requirements (it must be
some kind of integer, and it must be signed), but by and
large the system may choose whatever type it finds convenient.

And that's why you are better off not worrying about
what "real" type happens to lie behind a pid_t: It means
your program is not restricted to running only on a Mazda.

--
Eric Sosman
esosman@ieee-dot-org.invalid

Sanchit <sanchitgupta.1@gmail.com> writes:
> pid_t is a data type defines in types.h
> but is it realy necessary to use it.. I mean it is a
> signed integer type only.. then why should pid_t be used??

The idea behind this is that different (UNIX(*)-)implementations can
use different type for process IDs if there is a reason to do
so. Especially, this means that a pid_t could be smaller than an int
if conserving space was an important concern. For application code,
this only matters insofar (easy) source code portability to different
systems is of concern.

Logan Shaw <lshaw-usenet@austin.rr.com> writes:
> Sanchit wrote: 
>
> If you use pid_t, it will be fine in every case.  If you use
> long, there are no guarantees.  If you use pid_t, you will be
> using what the producers of the system have tested.  If you
> use long, you will be using something that is unsupported and
> untested.

A 'typedef-name' is just an alias for an existing type. This means
that if an implementation had a

typedef long pid_t

the only difference between the two would be that usage looked
different in source code. One of the nice properties of C is that
'types' stick to objects and not to values: A value originally
returned be fork can be stored into anything large enough to represent
it without being "damaged" and a compiler is required to not introduce
artificial differences between identically valued numbers coming from
different origins.

Rainer Weikusat wrote:
> Logan Shaw <lshaw-usenet@austin.rr.com> writes: 
>
> A 'typedef-name' is just an alias for an existing type. This means
> that if an implementation had a
>
> 	typedef long pid_t
>
> the only difference between the two would be that usage looked
> different in source code. One of the nice properties of C is that
> 'types' stick to objects and not to values: A value originally
> returned be fork can be stored into anything large enough to represent
> it without being "damaged" and a compiler is required to not introduce
> artificial differences between identically valued numbers coming from
> different origins.

OK, my statement is not true on implementations where the actual
type of pid_t is long.  But I suspect that doesn't cover very many
implementations.  It certainly doesn't cover the one I'm using
right now.

- Logan

Logan Shaw <lshaw-usenet@austin.rr.com> writes:
> Rainer Weikusat wrote: 
>
> OK, my statement is not true on implementations where the actual
> type of pid_t is long.

Your statement is never really true. A pid_t can be stored in a long
without any risk if its value can be represented as a long, ie if its
'pure binary representation'[*] needs at most

(sizeof(long) * CHAR_BIT) - 1

value bits.

[*] ISO/IEC 9899:1999, 6.2.6.2|1

As I wrote above: The semantics of C demand that numerical values are
to be preserved if possible, ie if the type of an object someone tries
to store the value in is large enough to represent it, no matter what
type the object the value came from had. It's not Pascal (or Ada)
where a compiler is supposed to create artificial mischief based on
'racially discriminating' numerical values :-).