why i value doesn't change ?

[sophia.agnes]

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 ?

[Marco Manfredini]

so**********@gmail.com 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.

[Willem]

so**********@gmail.com 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

[Kenny McCormack]

In article <fi**********@aioe.org>,
Marco Manfredini <ok**********@phoyd.netwrote:

>so**********@gmail.com 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.

[CBFalconer]

so**********@gmail.com wrote:

>
consider the following program

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

Reading stops here. There is no <unistd.hin 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

[Marco Manfredini]

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

[jacob navia]

Kenny McCormack wrote:

In article <fi**********@aioe.org>,
Marco Manfredini <ok**********@phoyd.netwrote:

>so**********@gmail.com 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

[CBFalconer]

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

[santosh]

In article <fi**********@news.xmission.com>, Kenny McCormack
<ga*****@xmission.xmission.comwrote on Sunday 25 Nov 2007 10:46 pm:

In article <fi**********@aioe.org>,
Marco Manfredini <ok**********@phoyd.netwrote:

>>so**********@gmail.com 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.

[Joachim Schmitz]

"CBFalconer" <cb********@yahoo.comschrieb im Newsbeitrag
news:47***************@yahoo.com...

so**********@gmail.com wrote:

>>
consider the following program

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

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

Which she did...

Bye, Jojo

[Kelsey Bjarnason]

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

[James Kuyper]

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.

[pete]

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

[Kenny McCormack]

In article <47***********@mindspring.com>,
pete <pf*****@mindspring.comwrote:

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

[Marco Manfredini]

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

[Willem]

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

[Marco Manfredini]

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

[Kenny McCormack]

In article <sl********************@snail.stack.nl>,
Willem <wi****@stack.nlwrote:

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

[Willem]

Kenny wrote:
) In article <sl********************@snail.stack.nl>,
) Willem <wi****@stack.nlwrote:
)>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

[Richard Tobin]

In article <sl********************@snail.stack.nl>,
Willem <wi****@stack.nlwrote:

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

[Stephen Sprunk]

"Marco Manfredini" <ok**********@phoyd.netwrote in message
news:fi**********@aioe.org...

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

[Stephen Sprunk]

<so**********@gmail.comwrote in message
news:7f**********************************@e23g2000 prf.googlegroups.com...

#include<unistd.h>

<unistd.hisn'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

[Kenny McCormack]

In article <sl********************@snail.stack.nl>,
Willem <wi****@stack.nlwrote:

>Kenny wrote:
) In article <sl********************@snail.stack.nl>,
) Willem <wi****@stack.nlwrote:
)>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.

[Marco Manfredini]

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

[CBFalconer]

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

[Kenny McCormack]

In article <47***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:

>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!"); }

[Francine.Neary]

On Nov 27, 10:54 pm, [e-mail] (Kenny McCormack)
wrote:

In article <[e-mail]>,
CBFalconer <[e-mail]:

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

[=?UTF-8?q?Harald_van_D=C4=B3k?=]

On Tue, 27 Nov 2007 15:08:09 -0800, Francine.Neary wrote:

On Nov 27, 10:54 pm, [e-mail] (Kenny McCormack)
wrote:

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

No, it is the attempt to use the return value of a call to fork() that
invokes undefined behaviour. "This", the function, is entirely valid.

[Kenny McCormack]

In article <81**********************************@w34g2000hsg. googlegroups.com>,
<Fr************@googlemail.comwrote:
....

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

[CBFalconer]

Fr************@googlemail.com wrote:

[e-mail] (Kenny McCormack) wrote:

>CBFalconer <[e-mail]:

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

[pete]

Marco Manfredini wrote:

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

It means fork is on topic in another newsgroup.
The problem is that most programmers
find "comp.lang.c" too easy to spell,
while finding a newsgroup where forks are on topic
is too difficult.

--
pete

[pete]

Willem wrote:

>
Kenny wrote:
) In article <sl********************@snail.stack.nl>,
) Willem <wi****@stack.nlwrote:
)>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.

It has nothing to do with it.
Lots of standard C library functions
can't be implemented portably in C,
but they're all on topic.

You really shouldn't reply to "Kenny".
It's just a Markov text generator.

--
pete

[Charlie Gordon]

"CBFalconer" <cb********@yahoo.coma écrit dans le message de news:
47***************@yahoo.com...

Fr************@googlemail.com wrote:

>[e-mail] (Kenny McCormack) wrote:

>>CBFalconer <[e-mail]:
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.

Non sequitur.

puts can return EOF or a non negative value, where do you get that it cannot
be zero?
This implementation of fork can be easily fixed in many ways: an easy one
consists in inserting the return keyword in front of puts.

--
Chqrlie.

[CBFalconer]

Charlie Gordon wrote:

"CBFalconer" <cb********@yahoo.coma écrit:

.... snip ...

>

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

Non sequitur.

puts can return EOF or a non negative value, where do you get that
it cannot be zero? This implementation of fork can be easily
fixed in many ways: an easy one consists in inserting the return
keyword in front of puts.

I think I misread 'non-negative' as 'non-zero' in the following:

7.19.7.10 The puts function

Synopsis
[#1]
#include <stdio.h>
int puts(const char *s);

Description

[#2] The puts function writes the string pointed to by s to
the stream pointed to by stdout, and appends a new-line
character to the output. The terminating null character is
not written.

Returns

[#3] The puts function returns EOF if a write error occurs;
otherwise it returns a nonnegative value.

My mistake. Sorry. Well caught.

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