pid_t data type

Rainer Weikusat <rweikusat@mssgmbh.com> 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.
>

Interfaces like posix_spawn() return the PID through a pointer. Off the top
of my head it's the only counter-example, but all the same it would be
foolish to exclude third party libraries or other user code to excuse a
practice which is, at best, poor programming hygiene.

I don't use typedef nearly as much as others, but pid_t is one of the best
examples of appropriate use, after, say size_t, off_t, and sig_atomic_t.
(The last is probably most relevant, because its [barely] reasonable to say
that pid_t will never need to be a 64-bit type, unless this multi-core fad
really gets out of control, or maybe a 128-bit type if we got global-scale
clusters.)

William Ahern <william@wilbur.25thandClement.com> writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote: 
> 
> 
> 
>
> Interfaces like posix_spawn() return the PID through a pointer.
> Off the top of my head it's the only counter-example,

It's a statement about something completely different. As such, it
cannot be 'a counter example' for another 'something completely
different'.

[...]

> I don't use typedef nearly as much as others, but pid_t is one of the best
> examples of appropriate use,

Of course it is 'appropriate': It enables an implementation to use a
'fitting' specific signed integer type, with the most likely example
still being a 16-bit type to save space. But this neither means that
it is not just an alias for another signed integer type nor that pid_t
values would be 'something magical' -- they are just signed integer
values and any object with a type suitable for representing the value
can be used to store it.

On Mar 16, 10:28 pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> Logan Shaw <lshaw-use...@austin.rr.com> writes: 
> 
>
> 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 :-).

I am really unable to understand your reply...
We know that process id will be an integer ( I an not specifying here
a range). And long is able to represent large value of integers (the
maximum a machine can represent). So every PID should be able to pe
represnted by long. And here numeric values will be preserved,,,,

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


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!

Sanchit <sanchitgupta.1@gmail.com> writes:
> On Mar 16, 12:34 pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:

[...]
 
>
>
> Are you sure pid_t is typedef of long..

I never claimed that. It could be 'long'. It could be 'short'. It
could be any (signed) integer type.

> I really dont know. As on my machine sizeof(pid_t)= sizeof(int)

For 'typical' 32-bit machines, sizeof(long) will be the same as
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!

Then you obviously don't want an answer for your question. If you want
to know if 'type X' will always be large enough to store a value
supposed to be stored in a 'type Y' variable, you will need to know
what Y actually is.

On Mar 17, 8:55 pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> Sanchit <sanchitgupt...@gmail.com> writes: 
>
> [...]
> 
> 
> 
> 
>
> I never claimed that. It could be 'long'. It could be 'short'. It
> could be any (signed) integer type.
> 
>
> For 'typical' 32-bit machines, sizeof(long) will be the same as
> sizeof(int).
> 
>
> Then you obviously don't want an answer for your question. If you want
> to know if 'type X' will always be large enough to store a value
> supposed to be stored in a 'type Y' variable, you will need to know
> what Y actually is.

Thanks,,, So how can i find range of pid_t??

>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, you'll be passing
an argument of the wrong size and it is likely to be interpreted
incorrectly.  This is preventable with good programming style (use
prototypes).

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
preventable with good programming styple, and you probably want to
cast it to a intmax_t.

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.
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).  This is preventable by using pid_t rather than long.

4.  If you ever use a pointer-to-pid_t anywhere, it has to point
to something of the correct size.  I don't know of any existing
system functions that do that.  This might change.

Sanchit wrote:
> And long is able to represent large value of integers (the
> maximum a machine can represent).

This is where you're ; there is such a thing as a long long. And
even beyond that there are always ways, even if not natural for the
machine architecture, of representing values of any size.

RM

On Mar 18, 4:35 am, gordonb.fy...@burditt.org (Gordon Burditt) wrote: 
>
> 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, you'll be passing
> an argument of the wrong size and it is likely to be interpreted
> incorrectly.  This is preventable with good programming style (use
> prototypes).
>
> 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
> preventable with good programming styple, and you probably want to
> cast it to a intmax_t.
>
> 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.
> 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).  This is preventable by using pid_t rather than long.
>
> 4.  If you ever use a pointer-to-pid_t anywhere, it has to point
> to something of the correct size.  I don't know of any existing
> system functions that do that.  This might change.

Thnx... But i dont agree with ur 2nd point.. i printf pid_t type like
intergers only by using %d and it is working fine...

On Mar 18, 2:48 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:

> Quoting SUS/ c99:
>
>         All implementations shall support one or more environments where t
he
>         widths of the following types are no greater than the width of typ
e
>         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

That such an environment must be supported doesn't mean that he will
be in such an environment. In fact, you just found an additional
limitation to storing a pid_t in a long -- you may be forced to use a
SUS/c99 environment other than the one you might want to use for other
reasons.

DS