pid_t data type - Unix

This is a discussion on pid_t data type - Unix ; 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??...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 52

Thread: pid_t data type

  1. pid_t data type

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

  2. Re: pid_t data type

    Sanchit wrote:

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


    Perhaps. In any case, what /size/ (or type, if you will) of integer is it?
    Is it a short int, an int, a long int, or a long long int?

    > then why should pid_t be used??


    So that you don't /have/ to know what type of integer the implementation
    uses for a pid value.


    --
    Lew Pitcher

    Master Codewright & JOAT-in-training | Registered Linux User #112576
    http://pitcher.digitalfreehold.ca/ | GPG public key available by request
    ---------- Slackware - Because I know what I'm doing. ------



  3. Re: pid_t data type

    On Mar 15, 10:59 pm, Lew Pitcher wrote:
    > Sanchit wrote:
    > > 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..

    >
    > Perhaps. In any case, what /size/ (or type, if you will) of integer is it?
    > Is it a short int, an int, a long int, or a long long int?
    >
    > > then why should pid_t be used??

    >
    > So that you don't /have/ to know what type of integer the implementation
    > uses for a pid value.
    >
    > --
    > Lew Pitcher
    >
    > Master Codewright & JOAT-in-training | Registered Linux User #112576http://pitcher.digitalfreehold.ca/ | GPG public key available by request
    > ---------- Slackware - Because I know what I'm doing. ------


    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)

  4. Re: pid_t data type

    In article
    <1900a0b6-626c-434c-8660-2c269342d112@d21g2000prf.googlegroups.com>,
    Sanchit wrote:

    > On Mar 15, 10:59 pm, Lew Pitcher wrote:
    > > Sanchit wrote:
    > > > 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..

    > >
    > > Perhaps. In any case, what /size/ (or type, if you will) of integer is it?
    > > Is it a short int, an int, a long int, or a long long int?
    > >
    > > > then why should pid_t be used??

    > >
    > > So that you don't /have/ to know what type of integer the implementation
    > > uses for a pid value.

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


    It has nothing to do with memory management, it's about calling
    sequences. If your declarations of system calls don't match what the OS
    actually uses, the data won't be passed properly when you call them.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  5. Re: pid_t data type

    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.

    > are there any specific
    > case where we should use only pid_t and not long (any any int type)


    Yes, any case when you want to store a pid, you should use pid_t.
    You might not experience problems with a long instead, but since
    you don't know, and since it is just easy to use pid_t and pid_t
    provides better documentation and better readability, why would
    do it the other way and introduce potential problems for no
    benefit?

    - Logan

  6. Re: pid_t data type

    Sanchit wrote:
    > On Mar 15, 10:59 pm, Lew Pitcher wrote:
    >> Sanchit wrote:
    >>> 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..

    > [...]
    > 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)


    There is an automobile in my driveway. To move it
    from my driveway onto the public roads, I must have in
    my possession a driving license. My automobile happens
    to be a Mazda, but my driving license does not specify
    that I am licensed to drive Mazdas; it says I am licensed
    to drive passenger automobiles, vans, and light trucks
    of any make and model.

    There is a process in your system. To send it a signal,
    you must have in your possession a pid_t value that identifies
    the target process. On your system, the pid_t value happens
    to be an int, but the API does not specify that you must supply
    an int; it says that you must supply whatever the system uses
    as a pid_t, whatever type that turns out to be.

    My driving license is more flexible and useful because
    it is intentionally vague about the types of vehicles I
    may drive; there are a few restrictions (no motorcycles,
    for example), but by and large I may drive whatever make
    of car I like. The POSIX API gains similar flexibility and
    usefulness through similar intentional vagueness about the
    nature of pid_t; there are a few requirements (it must be
    some kind of integer, and it must be signed), but by and
    large the system may choose whatever type it finds convenient.

    And that's why you are better off not worrying about
    what "real" type happens to lie behind a pid_t: It means
    your program is not restricted to running only on a Mazda.

    --
    Eric Sosman
    esosman@ieee-dot-org.invalid

  7. Re: pid_t data type

    Sanchit writes:
    > 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??


    The idea behind this is that different (UNIX(*)-)implementations can
    use different type for process IDs if there is a reason to do
    so. Especially, this means that a pid_t could be smaller than an int
    if conserving space was an important concern. For application code,
    this only matters insofar (easy) source code portability to different
    systems is of concern.

  8. Re: pid_t data type

    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.


  9. Re: pid_t data type

    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. But I suspect that doesn't cover very many
    implementations. It certainly doesn't cover the one I'm using
    right now.

    - Logan

  10. Re: pid_t data type

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

  11. Re: pid_t data type

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


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


  12. Re: pid_t data type

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

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


  13. Re: pid_t data type

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

  14. Re: pid_t data type

    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!

  15. Re: pid_t data type

    Sanchit writes:
    > On Mar 16, 12:34 pm, Rainer Weikusat wrote:


    [...]

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

  16. Re: pid_t data type

    On Mar 17, 8:55 pm, Rainer Weikusat wrote:
    > Sanchit writes:
    > > On Mar 16, 12:34 pm, Rainer Weikusat wrote:

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


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

  17. Re: pid_t data type

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


  18. Re: pid_t data type

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


    This is where you're confused; 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

  19. Re: pid_t data type

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

  20. Re: pid_t data type

    gordonb.fy177@burditt.org (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.

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