Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > why i value doesn't change ?

Reply
Thread Tools

why i value doesn't change ?

 
 
Richard Tobin
Guest
Posts: n/a
 
      11-27-2007
In article <(E-Mail Removed)>,
Willem <(E-Mail Removed)> wrote:
>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.


All kinds of things break standard C. Using a debugger lets you
change variables. Using threads makes all kinds of things unsafe.
Using memory-mapping functions can completely mess everything up. You
can't expect everything about standard C to continue to be true when
you use libraries not written in pure standard-defined C. And a good
thing too.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
 
Reply With Quote
 
 
 
 
Stephen Sprunk
Guest
Posts: n/a
 
      11-27-2007
"Marco Manfredini" <(E-Mail Removed)> wrote in message
news:fick5p$mtv$(E-Mail Removed)...
> I'm just a curios visitor, bewildered by the customs of the local natives.


It's simple: if it's not ANSI/ISO C or K&R C, it's considered off-topic
here, though most people who will give that answer also provide a reference
to a group where the question is likely to be on-topic. For POSIX-y things,
e.g. fork(), that's usually comp.unix.programmer.

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


It's only inexplicable if that external library function is in conforming
ISO C. Of course, since ISO C does not permit fork() to do what it does,
that's obviously not correct. Specifically, ISO C does not acknowledge that
multiple programs can be running at the same time, therefore it has _no_
model of how the behavior of one program can (or can't) affect the behavior
of another running concurrently.

<OT>However, I find fork() an interesting example, because the program
before the call and the two programs after the call appear to be conforming;
they simply have two independent instances of the ISO C memory model,
initially inherited from the single initial instance but potentially
diverging. Without other non-portable interactions (e.g. IPC), they do not
interact in any way that is detectable by a conforming program.</OT>

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

 
Reply With Quote
 
 
 
 
Stephen Sprunk
Guest
Posts: n/a
 
      11-27-2007
<(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> #include<unistd.h>


<unistd.h> isn't ISO C; it's probably POSIX, which means you'll get better
answers in comp.unix.programmer.

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


<OT>
The short answer is that the parent and child each have their own copy of i
after fork() returns. That means you can change one but the other will stay
the same. On most modern machines, they will have the same virtual address
(what you see), but that's just a trick of the OS; they will have different
physical addresses*. You can't compare pointers from different processes,
since they're in different virtual address spaces.
</OT>

S

* Well, at least after one is modified. Some OSes use "copy on write" to
make forking faster. That's a minor detail; unless you're a kernel hacker,
it's fine to act as if all objects are duplicated at the time of forking.

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

 
Reply With Quote
 
Kenny McCormack
Guest
Posts: n/a
 
      11-27-2007
In article <(E-Mail Removed)>,
Willem <(E-Mail Removed)> wrote:
>Kenny wrote:
>) In article <(E-Mail Removed)>,
>) Willem <(E-Mail Removed)> 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.


Then you haven't been around here long enough. Stick around, kid,
you'll get it soon enough.

 
Reply With Quote
 
Marco Manfredini
Guest
Posts: n/a
 
      11-27-2007
Stephen Sprunk wrote:

> Of course, since ISO C does not permit fork() to do what it
> does,


We don't know what the OP's fork() usually does. We only know what it
did in this specific instance.

> that's obviously not correct. Specifically, ISO C does not
> acknowledge that multiple programs can be running at the same time,
> therefore it has _no_ model of how the behavior of one program can (or
> can't) affect the behavior of another running concurrently.


From the description of the OP is does not follow, that two programs ran
at the same time. Also, ISO-C allows the communication with a command
processor via "system" and leaves the details to the implementation

>
> <OT>However, I find fork() an interesting example, because the program
> before the call and the two programs after the call appear to be
> conforming; they simply have two independent instances of the ISO C
> memory model, initially inherited from the single initial instance but
> potentially
> diverging. Without other non-portable interactions (e.g. IPC), they
> do not interact in any way that is detectable by a conforming
> program.</OT>


The most interesing thing is, that in fact I *can* write a ISO-C program
which *may* show the observed behavior. Put this into a file named
"unistd.h":

/* implementation requirements according to 7.40.2.6/2:
works only if
- system("./f") starts the same program which calls fork()
- system("./f") does not return until said program terminates
- system("./f") continues the calling program in a conforming manner
- the file "state" is available for reading to the program which
system("./f") starts.
*/
int get_state()
{
int v;
FILE *p=fopen("state","r");
if (p==0) return 0;
v=fgetc(p);
fclose(p);
return v;
}
void set_state(int c)
{
FILE *p=fopen("state","w");
fputc(c,p);
fclose(p);
}
int fork()
{
FILE *p=0;
int pid;
int parent=0;
if (get_state()!=0) return 0;
set_state(1);
system("./f");
set_state(0);
return 1;
}

int wait(void *q)
{
}


--
IYesNo yes=YesNoFactory.getFactoryInstance().YES;
yes.getDescription().equals(array[0].toUpperCase());
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      11-27-2007
Marco Manfredini wrote:
> Kelsey Bjarnason 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.

>>
>> Not really.
>>

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


There is no such thing. fork() is not defined in ISO-C. If it was
defined it would not be implementable within the language (assuming
the usual meaning).

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

 
Reply With Quote
 
Kenny McCormack
Guest
Posts: n/a
 
      11-27-2007
In article <(E-Mail Removed)>,
CBFalconer <(E-Mail Removed)> wrote:
>Marco Manfredini wrote:
>> Kelsey Bjarnason 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.
>>>
>>> Not really.
>>>

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

>
>There is no such thing. fork() is not defined in ISO-C. If it was
>defined it would not be implementable within the language (assuming
>the usual meaning).


No, no, no. You've got it all wrong. As far as anyone in this NG is
concerned, the following is a perfectly good implementaion of "fork()"
and is absolutely to be considered as good or better than any other
implementation of "fork()":

int fork(void) { puts("Try a spoon instead!"); }

 
Reply With Quote
 
Francine.Neary@googlemail.com
Guest
Posts: n/a
 
      11-27-2007
On Nov 27, 10:54 pm, (E-Mail Removed) (Kenny McCormack)
wrote:
> In article <(E-Mail Removed)>,
> CBFalconer <(E-Mail Removed)> wrote:
> >Marco Manfredini wrote:
> >> Then please give an implementation of fork() in ISO-C.

>
> >There is no such thing. fork() is not defined in ISO-C. If it was
> >defined it would not be implementable within the language (assuming
> >the usual meaning).

>
> No, no, no. You've got it all wrong. As far as anyone in this NG is
> concerned, the following is a perfectly good implementaion of "fork()"
> and is absolutely to be considered as good or better than any other
> implementation of "fork()":
>
> int fork(void) { puts("Try a spoon instead!"); }


This invokes undefined behavior if the caller attempts to use the
return value of a call to fork().
 
Reply With Quote
 
Kenny McCormack
Guest
Posts: n/a
 
      11-28-2007
In article <(E-Mail Removed)>,
<(E-Mail Removed)> wrote:
....
>This invokes undefined behavior if the caller attempts to use the
>return value of a call to fork().


Fixing this is left as an exercise for the reader. I'm sure you'll be
up to the task.

 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      11-28-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> (E-Mail Removed) (Kenny McCormack) wrote:
>> CBFalconer <(E-Mail Removed)> wrote:
>>> Marco Manfredini wrote:
>>>
>>>> Then please give an implementation of fork() in ISO-C.

>>
>>> There is no such thing. fork() is not defined in ISO-C. If it
>>> was defined it would not be implementable within the language
>>> (assuming the usual meaning).

>>
>> No, no, no. You've got it all wrong. As far as anyone in this
>> NG is concerned, the following is a perfectly good implementaion
>> of "fork()" and is absolutely to be considered as good or better
>> than any other implementation of "fork()":
>>
>> int fork(void) { puts("Try a spoon instead!"); }

>
> This invokes undefined behavior if the caller attempts to use the
> return value of a call to fork().


Since puts always returns a non-zero int, it is easily corrected.

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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
A Paradise DNS address change? What change? There was no change. Tony Neville NZ Computing 7 09-22-2006 01:02 PM
Change the value of an attribute according to the value of another attribute patrizio.trinchini@googlemail.com XML 8 08-22-2006 02:53 PM
Radio Button lost it`s checked value after few time change value BobbyMy ASP .Net Web Controls 0 08-27-2005 03:04 AM



Advertisments