Re: pid_t data type

gordonb.fy177@xxxxxxxxxxx (Gordon Burditt) writes:
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!

Yes, there are.

1. On a system where sizeof(int) != sizeof(long), and pid_t is
long, and you don't have a proper prototype in scope for the function
you are calling that takes a pid_t as an argument,

... then you are preventing proper conversion of actual arguments by a
compiler meaning, arguments won't be converted.

2. If you pass a pid_t to printf() without casting it, you'll have
to use the correct format or it will likely screw up.

This is the same as case 1): When automatic conversions cannot happen,
and the default argument conversions are not sufficient either, the
types of the actual arguments must match the types of the expected
arguments.

But it is very unlikely that the OP was refering to either subroutine
calls with argument conversion voluntarily prevented and mismatching
actual type or trying to pass arguments of incorrect types through an
elipsis: Both are programming errors and the behaviour of code trying
to do one or the other would be undefined. Questions relating to
undefined behaviour cannot be answered because it is undefined.

Demonstrating that it is possible to add something to the statements
in some original text such that the combined statement resulting
from doing so is obviously wrong only demonstrates that the person who
did is capable of thinking of obvious nonsense, but exactly nothing
about the original statement.

3. On a system where sizeof(pid_t) > sizeof(long), a long won't
hold a whole pid_t, and putting it in a long will likely mangle it.

This is bull*** (used with the usual 'marketing meaning' of purposely
not telling the truth to convince someone of a factually wrong opinion
one would like him to have for one's own convenience): In a 'simple
assignment', the value of the right operand is converted to the type
of the left operand (6.5.16.1|2) and the requirements for converting
integer values to specific integer types (6.3.1.3.1) demand that

When a value with integer type is converted to another
integer type other than _Bool, if the value can be represented
by the new type, it is unchanged.

The conclusion that

sizeof(pid_t) > sizeof(long) =>
the representation of a pid value needs more value bits
than a long has

is wrong: The size of some integer type communicates exactly nothing
about the size of minimal pure binary representation of 'random'
values stored in objects of such a type.

It is possible that a pid_t might in the future contain an IPv8
address, a digital signature, and certificates for the signature
along with a number that's very difficult to guess (perhaps 8Kbytes
total).

Quoting SUS/ c99:

All implementations shall support one or more environments where the
widths of the following types are no greater than the width of type
long:

blksize_t, cc_t, mode_t, nfds_t, /pid_t/, ptrdiff_t, size_t,
speed_t, ssize_t, suseconds_t, tcflag_t, useconds_t, wchar_t,
wint_t

Speculations about possible future technology developments are usually
called 'science fiction' and empirical evidence which can easily be
gathered from the last fifty years of 'science fiction' suggest that
such speculations will usually be wrong.
.