pid_t data type - Unix

This is a discussion on pid_t data type - Unix ; Casper H.S. Dik wrote: > "jason.cipriani@gmail.com" writes: > >> On Mar 18, 5:48 am, Rainer Weikusat wrote: >>> [snip] > >> Does it say somewhere that pid_t will never be a pointer type, or some >> other type, like a ...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 52 of 52

Thread: pid_t data type

  1. Re: pid_t data type

    Casper H.S. Dik wrote:
    > "jason.cipriani@gmail.com" writes:
    >
    >> On Mar 18, 5:48 am, Rainer Weikusat 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.

    >
    > It needs to be a signed airthmetic type:
    >
    > If pid is negative but not (pid_t)-1, sig will be sent to
    > all processes whose process group ID is equal to the abso-
    > lute value of pid and for which the process has permission
    > to send a signal.
    >
    > Since it needs to be used in comparisons it can't really be float...


    Why not? Can't the system restrict itself to the set of floating
    point values that can be exactly represented with no loss of
    precision (or overflow or whatever)? :-) Unless there's a
    requirement I don't know of that a pid_t can be added or subtracted
    or multiplied or something. It seems like the platform can choose
    the type of pid_t, so if the platform can know what a floating point
    type can exactly represent, it could use a floating point type
    for pid_t.

    Getting back to the semi-practical realm, I could actually imagine a
    system where a pid_t is some sort of huge integral type, where
    the pid_t is a cryptographically-secure uuid or guid. It'd make
    it hard to do attacks where you guess the pid of something. And
    it'd also eliminate a lot of worries about stale pid files. (One
    less sanity check necessary before you do that "kill" to make sure
    the old instance is dead.)

    - Logan

  2. Re: pid_t data type

    Logan Shaw writes:

    >Getting back to the semi-practical realm, I could actually imagine a
    >system where a pid_t is some sort of huge integral type, where
    >the pid_t is a cryptographically-secure uuid or guid. It'd make
    >it hard to do attacks where you guess the pid of something. And
    >it'd also eliminate a lot of worries about stale pid files. (One
    >less sanity check necessary before you do that "kill" to make sure
    >the old instance is dead.)


    VMS, for instance, used the lower 16-bits as a 'slot' number and
    the upper 16-bits as a generation number, specifically to avoid
    this issue.

    scott

  3. Re: pid_t data type

    On 2008-03-19, William Ahern wrote:
    > Rainer Weikusat wrote:
    >> William Ahern 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.

    >>
    >> What you believe about me is in your mind.

    >
    > Neo?
    >


    Are you sure you want to take the red pill?

    --


  4. Re: pid_t data type

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

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


  5. Re: pid_t data type

    Logan Shaw writes:
    > Casper H.S. Dik wrote:
    >> "jason.cipriani@gmail.com" writes:
    >>
    >>> On Mar 18, 5:48 am, Rainer Weikusat 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.

    >> It needs to be a signed airthmetic type:
    >> If pid is negative but not (pid_t)-1, sig will be sent to
    >> all processes whose process group ID is equal to the abso-
    >> lute value of pid and for which the process has permission
    >> to send a signal.
    >> Since it needs to be used in comparisons it can't really be float...

    >
    > Why not? Can't the system restrict itself to the set of floating
    > point values that can be exactly represented with no loss of
    > precision (or overflow or whatever)? :-) Unless there's a
    > requirement I don't know of that a pid_t can be added or subtracted
    > or multiplied or something.


    Various data structures used for searching for keys (eg hash tables or
    digital search tries) make use of their numerical properties.

  6. Re: pid_t data type

    Rainer Weikusat writes:
    >Logan Shaw writes:
    >> Casper H.S. Dik wrote:
    >>> "jason.cipriani@gmail.com" writes:
    >>>
    >>>> On Mar 18, 5:48 am, Rainer Weikusat 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.
    >>> It needs to be a signed airthmetic type:
    >>> If pid is negative but not (pid_t)-1, sig will be sent to
    >>> all processes whose process group ID is equal to the abso-
    >>> lute value of pid and for which the process has permission
    >>> to send a signal.
    >>> Since it needs to be used in comparisons it can't really be float...

    >>
    >> Why not? Can't the system restrict itself to the set of floating
    >> point values that can be exactly represented with no loss of
    >> precision (or overflow or whatever)? :-) Unless there's a
    >> requirement I don't know of that a pid_t can be added or subtracted
    >> or multiplied or something.

    >
    >Various data structures used for searching for keys (eg hash tables or
    >digital search tries) make use of their numerical properties.


    1) such data structures are usuall kernel-resident and algorithms to
    manipulate them reflect the choice of pid_t content.

    2) Most searching is searching for bitwise equality (pid_t [!=]= pid_t).

    3) Applications that assume a numeric relationship between pid_t values
    are broken.

    scott

  7. Re: pid_t data type

    scott@slp53.sl.home (Scott Lurndal) writes:
    > Rainer Weikusat writes:
    >>Logan Shaw writes:


    [abstract process id type]

    >>> Unless there's a requirement I don't know of that a pid_t can be
    >>> added or subtracted or multiplied or something.

    >>
    >>Various data structures used for searching for keys (eg hash tables or
    >>digital search tries) make use of their numerical properties.

    >
    > 1) such data structures are usuall kernel-resident and algorithms to
    > manipulate them reflect the choice of pid_t content.


    Data structures intended to efficiently provide 'associative arrays'
    (for specific key-set/ value-set pairs) are certainly not 'usually
    kernel-resident'. I assume that you meant to write that 'process
    management' (using such data structures to map process ids to some
    per-process information structure(s)) is 'usually [only] done by the
    kernel'. The simple counterexample for that would be a server using
    pre-forked processes to serve multiple clients concurrently. One I
    happen to have written is used to provide (HIPAA) 'secure download of
    files containing data to print' to appliances 'on the internet' (the
    more well-known example would be Apache 1 ;-): A supervisor process
    keeps track of which of its children are presently busy serving
    download requests or idle, forking new children or killing idle
    children based on some thresholds for 'MaxSpareServers' and
    'MinSpareServers' and logs 'accounting records' tracking what is/ was
    going on at some time.

    > 2) Most searching is searching for bitwise equality (pid_t [!=]=
    > pid_t).


    I was specifically referring to two search data structures whose
    associated algorithms perform calculations with keys (to determine a
    hash value or to extract certain bits for a digital search).

    > 3) Applications that assume a numeric relationship between pid_t values
    > are broken.


    pid_t is required to be a signed integer type. This means that process
    ID values must be integral numbers. Numbers have 'numeric
    relationships' with 'other numbers', no matter what other meanings may
    be associated with them in certain contexts. One property numbers,
    being entirely abstract entities, don't have is 'a colour': There is
    no such thing as 'a black zero' which would be different from 'a red
    zero', the latter having something specific in common with 'a red one'
    but not with 'a yellow five'. 'Colour' can here server as a substitute
    for 'arbitrary set of disjoint attributes associated with
    numbers'. Some people, eg then inventors of Ada, consider this to be
    an error (eg an algorithm determining twice the number of some number
    of cars should not 'just work' to determine twice the number of some
    number of submarines, too). If those 'some people' had come up with
    this original idea in elementary school, the net-effect would have
    been a bad grade instead.

    Which leads to the conclusion that 'teaching basic math' to pupils
    inherently leads to 'great security risks' and presumably should be
    avoided to eliminate really horrendous "error classes" :->.




  8. Re: pid_t data type

    Sanchit wrote:
    > On Mar 16, 10:28 pm, Rainer Weikusat wrote:
    >> Logan Shaw writes:
    >>> Rainer Weikusat wrote:
    >>>> Logan Shaw 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
    >>>>> untested.
    >>>> 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.
    >>> OK, my statement is not true on implementations where the actual
    >>> type of pid_t is long.

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


    As an adjunct, one more reason to use pid_t (and all other such types)
    is memory. As minor as it is, if your system stores PIDs as something,
    say a short, and you allocate a long, the memory usage to store your
    PIDs increases by some arbitrary amount defined by the implementation.
    This might well amount to less than 16 bytes, but it's still worth noting.

    Even more, the use of pid_t makes your intent considerably clearer to
    people trying to read your source, in the same way that typing INT_MAX
    instead of whatever value that comes out to on your system makes your
    intent much clearer. It says you are storing a PID (or using the
    maximum value of an integer) rather than some arbitrary number (or using
    some other arbitrary and usually messy-looking number).

    --
    --Falcon Kirtaran

  9. Re: pid_t data type

    Sanchit wrote:
    > On Mar 16, 12:34 pm, Rainer Weikusat wrote:
    >> Logan Shaw 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
    >>> untested.

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

  10. Re: pid_t data type

    Sanchit wrote:
    > On Mar 18, 4:35 am, gordonb.fy...@burditt.org (Gordon Burditt) 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, 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...


    Of *course* it does if its size is equal to that of an int in your
    implementation. Suppose you programmed this on a system where it was a
    short (%hd), or a long (%ld). Then you would find that it would not
    work, and would probably corrupt your stack frame and cause a segfault.

    --
    --Falcon Kirtaran

  11. Re: pid_t data type

    Falcon Kirtaran writes:
    > Sanchit wrote:


    [...]

    >> I just want you to tell me
    >> if there are cases where long will fail to take place of pid_t.


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


    pid_t is required to be a signed integer type and as such, it has an
    upper limit on its size. An implementation is required to support a
    programming environment where sizeof(pid_t) <= sizeof(long) is true.

    The remark about 'sizes of long' is completely out of place.

    BTW, the last time I checked this, UNIX(*) standards where defined by
    IEEE/ The Open Group and not by 'Falcon Kirtaran and his namesless
    buddies'.


  12. Re: pid_t data type

    Rainer Weikusat wrote:

    > BTW, the last time I checked this, UNIX(*) standards where defined by
    > IEEE/ The Open Group


    Nit-pick: they are defined by IEEE, The Open Group, and ISO.

    --
    Geoff Clare

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3