why i value doesn't change ?

Discussion in 'C Programming' started by sophia.agnes@gmail.com, Nov 25, 2007.

  1. Guest

    Dear all,

    consider the following program

    #include<stdio.h>
    #include<unistd.h>

    main()
    {
    int pid,*i,j;

    i = &j;
    *i= 10;

    pid = fork();

    if(pid == 0)
    {
    printf("\n address of i = %p",i);
    printf("\n initially i value in child = %d",*i);
    *i = *i +10;
    printf("\n after incrementation i value in child = %d",*i);
    puts("Child terminated....");
    }
    else
    {
    wait( (int*) 0);

    printf("\n address of i = %p",i);
    printf("\n value of i in parent = %d",*i);
    }

    i am getting o/p as:-

    address of i = 0xbfe6c01c
    initially i value in child = 10
    after incrementation i value in child = 20
    Child terminated....

    address of i = 0xbfe6c01c
    value of i in parent = 10

    the address of i is same in both parent and child process but
    the change made in child process is not reflected in the
    parent process why ?
     
    , Nov 25, 2007
    #1
    1. Advertising

  2. wrote:

    > the address of i is same in both parent and child process but
    > the change made in child process is not reflected in the
    > parent process why ?


    Looks like you have yet to understand what "process" means or fork()
    does. On many system, in particular those which have "fork()", every
    process has it's own memory, the OS sets things up that the memory
    address 0xbfe6c01c in process A points to a different RAM address than
    the same address in process B. That way every process can assume that
    nobody else will write into the memory of the process.

    You need threads or shared memory on these systems, if you want
    concurrent modification.
     
    Marco Manfredini, Nov 25, 2007
    #2
    1. Advertising

  3. Willem Guest

    wrote:
    ) the address of i is same in both parent and child process but
    ) the change made in child process is not reflected in the
    ) parent process why ?

    Suppose you're living in a house. You turn the bathroom light on. Then,
    your kid goes to live on her own, a few houses down the block. She decides
    to turn the bathroom light off, and she then writes in her blog 'I just
    turned off the bathroom light'. You check if this is true, but for some
    odd reason the bathroom light is still on.

    How is this possible ? The bathroom light switch is at exactly the same
    location in the house, after all.


    SaSW, Willem
    --
    Disclaimer: I am in no way responsible for any of the statements
    made in the above text. For all I know I might be
    drugged or something..
    No I'm not paranoid. You all think I'm paranoid, don't you !
    #EOT
     
    Willem, Nov 25, 2007
    #3
  4. CBFalconer Guest

    wrote:
    >
    > consider the following program
    >
    > #include<stdio.h>
    > #include<unistd.h>


    Reading stops here. There is no <unistd.h> in ISO standard C, so
    you are off topic. Try a Unix or Linux group.

    --
    Chuck F (cbfalconer at maineline dot net)
    <http://cbfalconer.home.att.net>
    Try the download section.



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Nov 25, 2007
    #4
  5. In article <fic5j1$63s$>,
    Marco Manfredini <> wrote:
    > wrote:
    >
    >> the address of i is same in both parent and child process but
    >> the change made in child process is not reflected in the
    >> parent process why ?

    >
    >Looks like you have yet to understand what "process" means or fork()
    >does. On many system, in particular those which have "fork()", every
    >process has it's own memory, the OS sets things up that the memory
    >address 0xbfe6c01c in process A points to a different RAM address than
    >the same address in process B. That way every process can assume that
    >nobody else will write into the memory of the process.


    What? No standard CLC answers? Nobody pointing out that some of the
    putative header files mentioned in this post do not exist - are not C,
    etc, etc? No pointing out that we have no idea what "fork" (and, for
    that matter, what about "spoon" and "knife") and "wait" (and "hesitate",
    "stop", and others...) are? Pointing out that we would need the OP to
    supply complete source code (in completely compliant ANSI C, of course)
    for these totally unknown functions, before we can even consider
    responding?

    Come on, guys. You're slipping...

    >You need threads or shared memory on these systems, if you want
    >concurrent modification.


    All completely OT, of course.
     
    Kenny McCormack, Nov 25, 2007
    #5
  6. Kenny McCormack wrote:
    >
    > What? No standard CLC answers? Nobody pointing out that some of the
    > putative header files mentioned in this post do not exist - are not C,
    > etc, etc? No pointing out that we have no idea what "fork" (and, for
    > that matter, what about "spoon" and "knife") and "wait" (and "hesitate",
    > "stop", and others...) are? Pointing out that we would need the OP to
    > supply complete source code (in completely compliant ANSI C, of course)
    > for these totally unknown functions, before we can even consider
    > responding?


    I'm just a curios visitor, bewildered by the customs of the local
    natives. Anyway, I could point out that this question *is* on-topic,
    because the OP found an external library function which seems to
    undermine C's memory model *completely*, an inexplicable behavior. A
    beginner may even wonder, if his/her inchoate proficiency of the
    language is the cause of a fallacy only resolvable by the courtesy of
    the knowing.

    cheers
     
    Marco Manfredini, Nov 25, 2007
    #6
  7. jacob navia Guest

    Kenny McCormack wrote:
    > In article <fic5j1$63s$>,
    > Marco Manfredini <> wrote:
    >> wrote:
    >>
    >>> the address of i is same in both parent and child process but
    >>> the change made in child process is not reflected in the
    >>> parent process why ?

    >> Looks like you have yet to understand what "process" means or fork()
    >> does. On many system, in particular those which have "fork()", every
    >> process has it's own memory, the OS sets things up that the memory
    >> address 0xbfe6c01c in process A points to a different RAM address than
    >> the same address in process B. That way every process can assume that
    >> nobody else will write into the memory of the process.

    >
    > What? No standard CLC answers? Nobody pointing out that some of the
    > putative header files mentioned in this post do not exist - are not C,
    > etc, etc? No pointing out that we have no idea what "fork" (and, for
    > that matter, what about "spoon" and "knife") and "wait" (and "hesitate",
    > "stop", and others...) are? Pointing out that we would need the OP to
    > supply complete source code (in completely compliant ANSI C, of course)
    > for these totally unknown functions, before we can even consider
    > responding?
    >
    > Come on, guys. You're slipping...
    >


    Its sunday...

    Happily they are sleeping late :)

    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Nov 25, 2007
    #7
  8. CBFalconer Guest

    Marco Manfredini wrote:
    >

    .... snip ...
    >
    > I'm just a curios visitor, bewildered by the customs of the local
    > natives. Anyway, I could point out that this question *is*
    > on-topic, because the OP found an external library function which
    > seems to undermine C's memory model *completely*, an inexplicable
    > behavior. A beginner may even wonder, if his/her inchoate
    > proficiency of the language is the cause of a fallacy only
    > resolvable by the courtesy of the knowing.


    This has nothing to do with the topicality, which is restricted to
    ISO standard C. The 'finding' of another external library doesn't
    affect that. As long as questions etc. deal with standard C we all
    know what the basis is, and no guesswork is needed.

    The 'knowing' can be restricted to the reading of the standard,
    which is generally available. However, this may be fairly tough on
    the newbie.

    --
    Chuck F (cbfalconer at maineline dot net)
    <http://cbfalconer.home.att.net>
    Try the download section.



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Nov 25, 2007
    #8
  9. santosh Guest

    In article <fical3$j6a$>, Kenny McCormack
    <> wrote on Sunday 25 Nov 2007 10:46 pm:

    > In article <fic5j1$63s$>,
    > Marco Manfredini <> wrote:
    >> wrote:
    >>
    >>> the address of i is same in both parent and child process but
    >>> the change made in child process is not reflected in the
    >>> parent process why ?

    >>
    >>Looks like you have yet to understand what "process" means or fork()
    >>does. On many system, in particular those which have "fork()", every
    >>process has it's own memory, the OS sets things up that the memory
    >>address 0xbfe6c01c in process A points to a different RAM address than
    >>the same address in process B. That way every process can assume that
    >>nobody else will write into the memory of the process.

    >
    > What? No standard CLC answers? Nobody pointing out that some of the
    > putative header files mentioned in this post do not exist - are not C,
    > etc, etc? No pointing out that we have no idea what "fork" (and, for
    > that matter, what about "spoon" and "knife") and "wait" (and
    > "hesitate", "stop", and others...) are? Pointing out that we would
    > need the OP to supply complete source code (in completely compliant
    > ANSI C, of course) for these totally unknown functions, before we can
    > even consider responding?
    >
    > Come on, guys. You're slipping...


    Not to worry. It was a slight oversight, now rectified.
     
    santosh, Nov 26, 2007
    #9
  10. "CBFalconer" <> schrieb im Newsbeitrag
    news:...
    > wrote:
    >>
    >> consider the following program
    >>
    >> #include<stdio.h>
    >> #include<unistd.h>

    >
    > Reading stops here. There is no <unistd.h> in ISO standard C, so
    > you are off topic. Try a Unix or Linux group.

    Which she did...

    Bye, Jojo
     
    Joachim Schmitz, Nov 26, 2007
    #10
  11. [snips]

    On Sun, 25 Nov 2007 20:58:40 +0100, Marco Manfredini wrote:

    > I'm just a curios visitor, bewildered by the customs of the local
    > natives. Anyway, I could point out that this question *is* on-topic,
    > because the OP found an external library function which seems to
    > undermine C's memory model *completely*, an inexplicable behavior.


    Not really.

    Each process ends up being, in essence, its own separate animal, using its
    own variables - so one wouldn't expect data modified in B to be reflected
    in A. Taken alone, each of A and B work consistently with what one would
    expect from the language - apart from the use of the non-standard elements.

    That is, the parent and child each work as if they were completely
    unrelated programs, self-contained - exactly what you'd expect. The fact
    one is spawned by the other doesn't really enter into it.

    What *would* be weird is if modifying variables in B actually _did_ cause
    variables in A to be altered; that _would_ mess with the whole
    conceptualization of how variables work in C. Usually you have to use
    some sort of inter-process communication, shared memory or suchlike to
    accomplish that sort of thing.
     
    Kelsey Bjarnason, Nov 27, 2007
    #11
  12. Kelsey Bjarnason wrote:
    > [snips]
    >
    > On Sun, 25 Nov 2007 20:58:40 +0100, Marco Manfredini wrote:
    >
    >> I'm just a curios visitor, bewildered by the customs of the local
    >> natives. Anyway, I could point out that this question *is* on-topic,
    >> because the OP found an external library function which seems to
    >> undermine C's memory model *completely*, an inexplicable behavior.

    >
    > Not really.
    >

    [...]

    Then please give an implementation of fork() in ISO-C.

    That's the point about "undermine C's memory model". The OP hit an
    library function which exposes a functionality that can not be explained
    or done within ISO-C's memory model and now she tries to find out if she
    possibly misunderstood something.

    Or put in a different form:

    --- Exercise 117 (advanced) ---
    Write a function v such that the following program:

    extern int v();
    int main(int argc, const char**argv)
    {
    const char *s=argv[1];
    if (v()) s=argv[2];
    printf("%s\n",s);
    }

    prints any two command line arguments in reverse order.

    Can it be done? Please cite from ISO/IEC 9899:1990 to support your
    arguments.
    ---
     
    Marco Manfredini, Nov 27, 2007
    #12
  13. James Kuyper Guest

    Kelsey Bjarnason wrote:
    ....
    > That is, the parent and child each work as if they were completely
    > unrelated programs, self-contained - exactly what you'd expect. ...


    That is what some people would expect; contrary expectations are the
    reason for the message that started this thread.
     
    James Kuyper, Nov 27, 2007
    #13
  14. pete Guest

    Marco Manfredini wrote:

    > I'm just a curios visitor, bewildered by the customs of the local
    > natives. Anyway, I could point out that this question *is* on-topic,
    > because the OP found an external library function which seems to
    > undermine C's memory model *completely*, an inexplicable behavior. A
    > beginner may even wonder, if his/her inchoate proficiency of the
    > language is the cause of a fallacy only resolvable by the courtesy of
    > the knowing.


    As far as posted C code goes:
    If posted C code can be part of the kind of
    code that can be translated and executed
    on any conforming C implementation, then it's on topic.
    If posted C code can't be part of that kind of code,
    then only the reason why it can't be, is on topic.

    I couldn't compile original posted code.

    I don't have unistd.h
    It's possible that various individuals may each have
    a different version of unistd.h
    unistd.h isn't described in the C standard.

    On the other hand, I do have stdio.h
    I can discuss code which depends on stdio.h with *anyone*
    because the C standard specifies the minimum required
    characteristics of stdio.h.

    --
    pete
     
    pete, Nov 27, 2007
    #14
  15. In article <>,
    pete <> wrote:
    >Marco Manfredini wrote:
    >
    >> I'm just a curios visitor, bewildered by the customs of the local
    >> natives. Anyway, I could point out that this question *is* on-topic,
    >> because the OP found an external library function which seems to
    >> undermine C's memory model *completely*, an inexplicable behavior. A
    >> beginner may even wonder, if his/her inchoate proficiency of the
    >> language is the cause of a fallacy only resolvable by the courtesy of
    >> the knowing.

    >
    >As far as posted C code goes:
    > If posted C code can be part of the kind of
    > code that can be translated and executed
    > on any conforming C implementation, then it's on topic.
    > If posted C code can't be part of that kind of code,
    > then only the reason why it can't be, is on topic.


    Translation: CLC is, in and of itself, a completely useless group; it's
    only purpose is to serve as a gateway to other, useful groups.
     
    Kenny McCormack, Nov 27, 2007
    #15
  16. pete wrote:

    > Marco Manfredini wrote:
    >
    >> I'm just a curios visitor, bewildered by the customs of the local
    >> natives. Anyway, I could point out that this question *is* on-topic,
    >> because the OP found an external library function which seems to
    >> undermine C's memory model *completely*, an inexplicable behavior. A
    >> beginner may even wonder, if his/her inchoate proficiency of the
    >> language is the cause of a fallacy only resolvable by the courtesy of
    >> the knowing.

    >
    > As far as posted C code goes:
    > If posted C code can be part of the kind of
    > code that can be translated and executed
    > on any conforming C implementation, then it's on topic.


    A conforming implementation allows the user to use code that is declared
    in header files and defined elsewhere. Quiz: Judging only the behavior
    described by the OP, can this mysterious "fork()" function be
    implemented in ISO-C? If not, what does that mean? Undefined behavior?

    --
    IYesNo yes=YesNoFactory.getFactoryInstance().YES;
    yes.getDescription().equals(array[0].toUpperCase());
     
    Marco Manfredini, Nov 27, 2007
    #16
  17. Willem Guest

    Marco wrote:
    ) Then please give an implementation of fork() in ISO-C.

    Why does the implementation have to be in ISO-C ?


    SaSW, Willem
    --
    Disclaimer: I am in no way responsible for any of the statements
    made in the above text. For all I know I might be
    drugged or something..
    No I'm not paranoid. You all think I'm paranoid, don't you !
    #EOT
     
    Willem, Nov 27, 2007
    #17
  18. Willem wrote:

    > Marco wrote:
    > ) Then please give an implementation of fork() in ISO-C.
    >
    > Why does the implementation have to be in ISO-C ?


    Is this thread crossposted to comp.lang.ada?

    --
    IYesNo yes=YesNoFactory.getFactoryInstance().YES;
    yes.getDescription().equals(array[0].toUpperCase());
     
    Marco Manfredini, Nov 27, 2007
    #18
  19. In article <>,
    Willem <> wrote:
    >Marco wrote:
    >) Then please give an implementation of fork() in ISO-C.
    >
    >Why does the implementation have to be in ISO-C ?


    If it isn't, we can't talk about it here.
     
    Kenny McCormack, Nov 27, 2007
    #19
  20. Willem Guest

    Kenny wrote:
    ) In article <>,
    ) Willem <> wrote:
    )>Marco wrote:
    )>) Then please give an implementation of fork() in ISO-C.
    )>
    )>Why does the implementation have to be in ISO-C ?
    )
    ) If it isn't, we can't talk about it here.

    The original claim was that fork() somehow *broke* standard-C.
    I don't see how having to implement it in C has anything to do with it.


    SaSW, Willem
    --
    Disclaimer: I am in no way responsible for any of the statements
    made in the above text. For all I know I might be
    drugged or something..
    No I'm not paranoid. You all think I'm paranoid, don't you !
    #EOT
     
    Willem, Nov 27, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?SlQ=?=
    Replies:
    1
    Views:
    3,654
    Hansen
    Jun 29, 2011
  2. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    904
    Mark Rae
    Dec 21, 2006
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,970
    Smokey Grindel
    Dec 2, 2006
  4. MZ
    Replies:
    7
    Views:
    830
    Ed Mullen
    Mar 17, 2008
  5. Disc Magnet
    Replies:
    3
    Views:
    735
    David Thompson
    Mar 24, 2010
Loading...

Share This Page