need to be enlightened on pid_t

[Grocery Clerk]

I know size_t (used for size of objects) is a 32-bit value on a 32-bit
system and 64-bit on a 64 bit system. This is explained on Page 29 of
Unix Network Programming: The Sockets Networking API. Can someone
please explain to me the reasoning behind pid_t?

 

[Jack Klein]

I know size_t (used for size of objects) is a 32-bit value on a 32-bit
system and 64-bit on a 64 bit system.

That may be true on some particular implementations that interest you,
but no such guarantee or requirement exists in the C language. size_t
is a typedef for an unsigned integer type, and C specifies that it is
large enough to hold the size of any object in bytes.

This is explained on Page 29 of
Unix Network Programming: The Sockets Networking API. Can someone
please explain to me the reasoning behind pid_t?

Nobody here can, because there is no 'pid_t' type defined by the
standard C language. If this is some extension provided on UNIX, you
need to ask about it in

 

[Malcolm]

I know size_t (used for size of objects) is a 32-bit value on a 32-bit
system and 64-bit on a 64 bit system. This is explained on Page 29 of
Unix Network Programming: The Sockets Networking API. Can someone
please explain to me the reasoning behind pid_t?

A size_t is the type yielded by the sizeof() operator, and also some
functions such as strlen(). This means that it must be big enough to hold
the largest object that the compiler can deal with. Normally this means that
it will be the same size as the address space of the processor, however
there is no guarantee (for instance an implementation might choose to
restrict objects to 64K for efficiency reasons on some architectures).

A pid_t is a separate type not in the C standard but defined by your Unix
library. It will hold something that is not a basic type (a number or
character on which it makes sense to do calculations), and not a memory size
either. The two reasons for defining a type are to make this clear, so that
all programmers know that variable x is a p_id and not just an arbitrary
integer, and so that the underlying system can be changed wthout breaking
underlying code, for instance we could move to a system where p_ids are
pointers rather than integer handles in the next release.

 

[Keith Thompson]

A pid_t is a separate type not in the C standard but defined by your Unix
library. It will hold something that is not a basic type (a number or
character on which it makes sense to do calculations), and not a memory size
either. The two reasons for defining a type are to make this clear, so that
all programmers know that variable x is a p_id and not just an arbitrary
integer, and so that the underlying system can be changed wthout breaking
underlying code, for instance we could move to a system where p_ids are
pointers rather than integer handles in the next release.

<OT>
As it happens, POSIX requires pid_t to be a signed integer type.
</OT>

 

[Fredrik Tolf]

I know size_t (used for size of objects) is a 32-bit value on a 32-bit
system and 64-bit on a 64 bit system. This is explained on Page 29 of
Unix Network Programming: The Sockets Networking API. Can someone
please explain to me the reasoning behind pid_t?

This isn't C, of course, but POSIX, so it's really off-topic here.

The thing is that POSIX likes to define a lot of typedefs to hold
datatypes that are supposed to be opaque to the programmer, like pid_t,
uid_t, gid_t, regex_t, socklen_t. These types, while usually defined as
different primitive integer types, are meant to be opaque, and thus only
certain operations are defined to work on them -- Usually things like
comparing to zero of below zero. The programmer may not assume anything
about their size either (except that returned by sizeof). That way,
implementors can deal with it in different ways while not breaking
programs that are compliant with the specified guidelines. For example,
32-bit Solaris may define a socklen_t to be 32 bits, while 64-bit
Solaris may define it to be 64 bits. Furthermore, some systems may have
16-bit UIDs, others 32-bit UIDs, and so on. Some may not even implement
it as integers, although that's probably rare, if it exists at all.

Fredrik Tolf