pid_t data type - Unix

This is a discussion on pid_t data type - Unix ; On Mar 17, 8:41 am, Sanchit 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 ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 52

Thread: pid_t data type

  1. Re: pid_t data type

    On Mar 17, 8:41 am, Sanchit 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

  2. Re: pid_t data type

    On Mar 18, 2:08 am, Sanchit 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

  3. Re: pid_t data type

    On Mar 18, 2:48 am, Rainer Weikusat wrote:

    > 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


    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

  4. Re: pid_t data type

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

  5. Re: pid_t data type

    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.

  6. Re: pid_t data type

    scott@slp53.sl.home (Scott Lurndal) writes:
    > Rainer Weikusat 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.


    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 asshole!!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'.

  7. Re: pid_t data type

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


    It does:

    Additionally:

    [...]


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



  8. Re: pid_t data type

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


  9. Re: pid_t data type

    Rainer Weikusat wrote:
    > 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'.


    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.

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


    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.


  10. Re: pid_t data type

    On Mar 18, 12:00 pm, Rainer Weikusat 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

  11. Re: pid_t data type

    In article
    <4ccdc3c0-8674-4425-8567-527a20e033a8@i7g2000prf.googlegroups.com>,
    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...


    Whether it works on any particular implementation depends on whether
    sizeof(int) == sizeof(pid_t). If sizeof(pid_t) > sizeof(int), it might
    work for small PIDs if byte order happens to match up properly.

    If you want to be sure that it gets passed properly, you need to declare
    and cast properly.

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

  12. Re: pid_t data type

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


    I used to make this sort of mistake all the time until finally it
    caused a program of mine to crash unexpectedly and I had to spend
    hours and hours tracking it down.

    I was doing this on another platform that had types like Int16 and
    Int32, and I passed these to a function much like printf() (one
    that takes a variable number of arguments). It "worked" until I
    changed some compiler options and some of my variables changed
    sizes as a result. Then it just started crashing.

    That's because the compiler generates machine code for the printf()
    implementation, and that implementation assumes the arguments (that
    correspond to %d) are a certain size. It has to know the size of
    them so that it can move them around, adjust the stack pointer, and
    so on. Then the compiler also generates code when you *call* printf(),
    and that code has to also move around values and adjust the stack
    pointer and stuff. When the values are not the same size, the stack
    pointer is off, or garbage bits are copied, or something else will
    go wrong, and your program will crash spectacularly.

    If you'd like to cause this kind of problem for yourself or someone
    else in the future, go ahead and write stuff like this:

    pid_t foo;
    printf("%d", foo); /* I like writing flaky code */

    But if you don't want to cause headaches for yourself and everyone,
    you should instead write code like this:

    pid_t foo;
    printf("%d", (int) foo);

    Or like this:

    pid_t foo;
    printf("%ld", (long) foo);

    Note that the last two examples aren't absolutely guaranteed to
    print anything meaningful, in case pid_t is larger than a long.
    But they will at least pass values to the function in a way that
    printf() can run without crashing.

    The general rule is, when you are using "%d" with printf(), always
    either use a variable or expression whose type is already for sure
    int, or cast the expression to an int. The compiler is relying on
    YOU to give it the correct type information. It has no other way
    of knowing. The only information about the type that printf()
    expects is the "%d" in the string, and the compiler cannot interpret
    that. So it must look at the type of the expression you give as
    an argument. A similar rule is to always make sure the expression's
    type is long if you use "%ld". (And 'double' for "%f" and so on.)

    - Logan

  13. Re: pid_t data type

    On Mar 18, 6:51 pm, Logan Shaw wrote:

    > Then the compiler also generates code when you *call* printf(),
    > and that code has to also move around values and adjust the stack
    > pointer and stuff. When the values are not the same size, the stack
    > pointer is off, or garbage bits are copied, or something else will
    > go wrong, and your program will crash spectacularly.


    Just to clarify, he means (I hope) that the stack pointer will be off
    or garbage bits will be copied in the implementation of 'printf'. The
    compiler will not copy garbage bits or any such thing.

    DS

  14. Re: pid_t data type

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

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.

  15. Re: pid_t data type

    Logan Shaw writes:

    >Or like this:


    > pid_t foo;
    > printf("%ld", (long) foo);


    >Note that the last two examples aren't absolutely guaranteed to
    >print anything meaningful, in case pid_t is larger than a long.
    >But they will at least pass values to the function in a way that
    >printf() can run without crashing.


    But only if the actual value of the pid is larger than the
    value which can be represented in int or long.

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.

  16. Re: pid_t data type

    On Mar 18, 12:09 pm, "jason.cipri...@gmail.com"
    wrote:

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


    That's definitely not what it says. It says such an environment must
    be supported, not that it must be the only one supported or that it
    must be the default. Storing a pid_t in a long may limit which
    environments you can use.

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


    What about cases where you need a pointer to something that holds a
    pid, like posix_spawn? What about cases where you need to pass a PID
    through a function with a '...' definition?

    DS

  17. Re: pid_t data type

    William Ahern writes:
    > Rainer Weikusat wrote:
    >> 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'.

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

  18. Re: pid_t data type

    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?


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

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


    Try it on a system where pid_t is long long or larger AND big-endian.
    Or on a system where sizeof(int) != sizeof(long) and pid_t is long
    and you are printing 3 integers, with the pid_t being the middle one.


  20. Re: pid_t data type

    David Schwartz wrote:
    > On Mar 18, 6:51 pm, Logan Shaw wrote:


    >> Then the compiler also generates code when you *call* printf(),
    >> and that code has to also move around values and adjust the stack
    >> pointer and stuff. When the values are not the same size, the stack
    >> pointer is off, or garbage bits are copied, or something else will
    >> go wrong, and your program will crash spectacularly.


    > Just to clarify, he means (I hope) that the stack pointer will be off
    > or garbage bits will be copied in the implementation of 'printf'. The
    > compiler will not copy garbage bits or any such thing.


    Well, whether the caller is copying garbage bits is sort of a
    philosophical question: if the caller assigns some meaning to
    them but the callee doesn't know the meaning, is there really
    any meaning there? In some hypothetical world where the callee
    understood what the caller meant, the information is not garbage.
    But that hypothetical by definition doesn't exist. The bits
    have a meaning according to the specs of some calling convention,
    but that meaning is only relevant as a set of rules that help a
    programmer use tools to produce correct code (where the caller
    and callee match up). Although I suppose you could argue that
    the state is meaningful when you step through with a debugger,
    and maybe that does matter.

    At any rate, the system as a whole will behave in a way which
    isn't intended. :-)

    - Logan

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