pid_t data type

gordonb.fy177@burditt.org (Gordon Burditt) writes: 
>
> 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 bullshit (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.

On Mar 17, 8:41 am, Sanchit <sanchitgupt...@gmail.com> wrote:

> 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. It will definitely fail on any machine where
sizeof(pid_t)>sizeof(int) or sizeof(pid_t)>sizeof(long). It may fail
in other ways, but it's not likely.

DS

On Mar 18, 2:08 am, Sanchit <sanchitgupt...@gmail.com> wrote:

> 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...

If all you care about is whether or not it works when you do it, and
it works when you did it, what are you asking?

DS

Rainer Weikusat <rweikusat@mssgmbh.com> writes:

>
>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.

The reason that pid_t as a type exists dates back to the massive
problems moving code from SVR3.2 with 16-bit pids to SVR4 with
32-bit pids.   Similarly for uid_t, gid_t.

Use the abstract type and a simple recompile fixes type changes.  Use
the underlying type, and every line of code must be inspected to find
uses of int as pid.

As usual with your diatribes, it is not clear what exactly you are
arguing for, but I would recommend that everyone who is using pids
in a program should use pid_t to represent it.

scott

On Mar 18, 5:48 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> [snip]

Does it say somewhere that pid_t will never be a pointer type, or some
other type, like a float (which, while strange, is fine since it's
hidden behind the typedef)? If it can be, then the discussion of using
longs or whatever interchangeably with pid_t's is moot.

scott@slp53.sl.home (Scott Lurndal) writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> writes: 
>
> The reason that pid_t as a type exists dates back to the massive
> problems moving code from SVR3.2 with 16-bit pids to SVR4 with
> 32-bit pids.   Similarly for uid_t, gid_t.

IOW, the reason that 'pid_t' exists is to enable implementations to
use different integer types to represent process IDs. I remember to
have written this myself at least once.

> Use the abstract type and a simple recompile fixes type changes.

IOW, a program which uses pid_t is 'source code portable' to
implementations using a different integer type than the one use to
originally implement the program. I have written this in my first
reply to 'sanchit'.

> Use the underlying type, and every line of code must be inspected to
> find uses of int as pid.

This would appear to be a trusim.

> As usual with your diatribes, it is not clear what exactly you are
> arguing for,

The term 'diatribe', insofar the dictionary translation is correct,
cannot possibly apply to a text criticzing the factual content of some
set of statements. OTOH, claiming that such a text would be 'a
diatribe' is a (miniscule) diatribe in itself. IOW, I have argued
against certain statements (coincidentally) made by some random person
and instead of arguing against what I wrote, you consider a personal
attack against me 'more appropriate', presumably comming from the
(all-to-common) misconception that 'factual critcisms' are, in fact,
just 'cleverly disguised personal attacks'.

As to what I am arguing for, this is actually very simple: In favor of
what I consider to be "the truth", as contained in the text itself.
The easiest way to prove that what I consider to be true is actually
false would be to demonstrate that. Instead of climbing on a soapbox,
pointing a finger at me, yelling "Look at this XXXXXXX!!1".

That your text used a less vulgar wording does not cause it to have a
different meaning.

> but I would recommend that everyone who is using pids
> in a program should use pid_t to represent it.

If source code portability of this particular program is an important
concern, this would be the most sensible way to handle pid_ts. But a
program using long to store pid_ts (minus special cases) will be
source code portable to all UNIX(*)-implementations, because SUS
demands that a programming environment where long is sufficient to
store pid_ts shall be supported.

But 'reasons why pid_t should be used' would be a question different
answer than 'reasons why it must be used'.

"jason.cipriani@gmail.com" <jason.cipriani@gmail.com> writes:
> On Mar 18, 5:48 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote: 
>
> Does it say somewhere that pid_t will never be a pointer type, or some
> other type, like a float (which, while strange, is fine since it's
> hidden behind the typedef)?

It does:

Additionally:

[...]


blksize_t, pid_t, and ssize_t shall be signed integer types.

<URL:http://www.opengroup.org/onlinepubs...g_1
3_67>

On Mar 18, 3:02 pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> "jason.cipri...@gmail.com" <jason.cipri...@gmail.com> writes: 
> 
>
> It does:
>
>      <URL:http://www.opengroup.org/onlinepubs...s/types.h.ht...
>

I see. It also says:

"The implementation shall support one or more programming environments
in which the widths of blksize_t, pid_t, size_t, ssize_t, suseconds_t,
and useconds_t are no greater than the width of type long."

If you take that to mean that *all* supported "programming
environments" have pid_t with width no greater than the width of type
long, then it *is* save to store pid_t's in a long. Is there something
that indicates that it's not?

If that's the case the only two issues with using long instead of
pid_t are:

1) If that standard changes some day, and

2) Using pid_t clearly indicates that the variable, function
parameter, etc., is meant to hold a process ID, and not some arbitrary
integer with another meaning. Saves on documentation.

It seems pretty simple, what is the argument about? If you are
prepared to face the consequences of 1 and 2 then you'd use longs, and
if you don't want to think about it then you'd use pid_t's. I think #2
is a big reason to use pid_t's. I also can't think of a compelling
reason to do it otherwise. If you are trying to store pid_t's as data
in a file, it may be more painless to just store them as text strings
(like the string "58123")... ?

Jason

Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> William Ahern <william@wilbur.25thandClement.com> writes: 

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

The counter example is to the implicit assumption in your response that the
only interfaces for which pid_t is applicable return its _value_ as through
an expression. With that assumption in mind, you then explained the
difference between values and representations.

But because posix_spawn() returns the _value_ of the PID _through_ a
pointer, your assumption is erroneous, and so your answer isn't dispositive
of the initial question. This is because pid_t might be an int; passing a
pointer to a long object would be invalid.
 

> 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.

The original inquiry was "why should pid_t be used". Later on, in this
sub-thread, the OP further elaborated, "So if i will use long... are there
any specific case where we should use only pid_t and not long". To which
Logan Shaw replied, "If you use long, there are no guarantees."

Again, your succinct exposition of values and representations in C doesn't
dispose of this question. You didn't disprove Logan's statement. If
anything, you merely explained why what the OP has already done--ostensibly
using fork(), getpid(), waitpid()--would likely continue to work, and is
reasonably if not absolutely portable. You've at best provided a
justification for what the OP has done (and appears to _want_ to do).

In that sense, one can see why people get the sense that your disinclination
to pay lip service to the party line--just use the typedef'd type
already--is misleading.

On Mar 18, 12:00 pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:

> If source code portability of this particular program is an important
> concern, this would be the most sensible way to handle pid_ts. But a
> program using long to store pid_ts (minus special cases) will be
> source code portable to all UNIX(*)-implementations, because SUS
> demands that a programming environment where long is sufficient to
> store pid_ts shall be supported.

You changed the question from the original question to one that had
the answer you wanted to give. Quoting the OP:

"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)"

and

"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!"

and

"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??"

This is not about storing pid_t's in longs. The OP wants to know when
you use pid_t and when you must use pid_t. The answer is, you use
pid_t, and you must use pid_t (to remain portable), to call any
function that takes a pid_t or a pointer to one.

DS