Re: pid_t data type

"jason.cipriani@xxxxxxxxx" <jason.cipriani@xxxxxxxxx> writes:
On Mar 18, 3:02 pm, Rainer Weikusat <rweiku...@xxxxxxxxxxx> wrote:
"jason.cipri...@xxxxxxxxx" <jason.cipri...@xxxxxxxxx> writes:
On Mar 18, 5:48 am, Rainer Weikusat <rweiku...@xxxxxxxxxxx> 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)?

It does:

<URL:http://www.opengroup.org/onlinepubs/000095399/basedefs/sys/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 a process id can be stored in an object of some particular integer
type does not depend on the type used to represent process ids by the
implementation but on the value of the process id. The maximum value
of the pid_t type limits the maximum possible value of a process id,
but this only means that the maximum actual value of it must be less
than or equal to the maximum representable value. The exact
particulars are presumably (AFAIK, SUS only demands that pid_t shall be a
signed integer type and that an actual process ID shall be positive)
implementation dependent.

Because a programming environment where a long is sufficient to hold
any possible value of a pid_t is supposed to exist, the conjecture
that 'usual implementations' will not use type larger than this
because of the additional implementation complexities associated with
doing so appears (to me) to be a reasonable one.

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

In the future, something which is yet unknown will happen. Because it
is not known yet, it can only be dealt with in future.

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.

Assuming that usage of a particular variable is not evident because
the context of its usage, a name documenting its purpose would be more
useful in this respect than a lone declaration somewhere in a file.

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.

Assume there is a subroutine calling multiple, different "UNIX(*)
calls", each returning either -1 to signal an error or some other
'useful value'. Because these usually return ints, a single int
variable with some suitable name can be used to store a 'return code',
copying actually useful 'useful values' somewhere else as desired. If
one of the calls was fork, a different return code variable or a
different way of handling return codes would be necessary just for
this single call. This means additional complications in the source
code for no 'real' benefit. Additionally, there are even situations
where the process id itself is of absolutely no interest, only if the
fork[*] succeeded. I have already (and would again) just used int in
such situations.

OTOH, I would always use pid_t for variables whose actual purpose is
to store process ids, because that's (as you have already written),
the easiest and most straight-forward option.


[*] I hereby humbly suggest that people fascinated by the idea
to 'spawn' new programs should just use and program for
operating systems more congenial to their
mentality. Especially, this would include everyone boneheaded
enough to assume that something which worked on computers
noone would use in a coffe maker nowadays needs to be changed
for "performance reasons" on present-day hardware. Present-day
software could well need a lot of changes for 'performance
reason', though. ...

.

Relevant Pages

  • Re: How to read a 8-bit grayscale JPEG image using C?
    ... int strlen ... and its reason for existence. ... I do most of my programming on parallel hardware. ... The programs contain operations on integers, characters, and reals. ...
    (comp.lang.c)
  • Re: Portability: Harmony between PC and microcontroller
    ... int is the natural integer type for the system. ... You are, perhaps unintentionally, paraphrasing the standard in a way ... One of the things that you might not realize is that the C programming ... In the real world, most embedded systems have more complex jobs to do, ...
    (comp.lang.c)
  • Re: What will be the next MAJOR programming language for commercial use?
    ... Variants can be considered as such a common OO pattern that it is worth ... Int of int ... As lists are built-in, they can be decomposed in a pattern just as they are ... features found in other state-of-the-art programming languages. ...
    (comp.lang.misc)
  • Re: OO versus RDB
    ... Because OO is a general purpose programming paradigm, and RDBMS are ... They are apples and oranges but they are both able to store ... Nothing about persistence here... ...
    (comp.object)
  • Re: Bug/Gross InEfficiency in HeathFields fgetline program
    ... Maybe this is true in the sort of programming you do, ... you are storing a list of amounts of money as integers. ... int average ... the array, rounded towards zero. ...
    (comp.lang.c)