Re: pid_t data type

Sanchit wrote:
On Mar 16, 12:34 pm, Rainer Weikusat <rweiku...@xxxxxxxxxxx> wrote:
Logan Shaw <lshaw-use...@xxxxxxxxxxxxx> writes:
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
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.

Are you sure pid_t is typedef of long.. I really dont know. As on
mymachine sizeof(pid_t)= sizeof(int)

And I think my question is misunderstood. I just want you to tell me
if there are cases where long will fail to take place of pid_t. I dont
care if pid_t is an int or short or long!

Your question is nonsensical. The answer is definitionally "yes" because pid_t in POSIX does not have an upper limit on its size, and the size of long is also implementation-defined in C.

In order to get around the problem of the length of PIDs and integer types being largely implementation-defined, we invented things like size_t and pid_t. Use them.

If you don't, your code is definitionally not portable (and might not even work on your own implementation, depending on the specifics of the implementation).

--Falcon Kirtaran