By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,805 Members | 1,056 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,805 IT Pros & Developers. It's quick & easy.

fork()

P: n/a
I was given the following code, and asked what the possible outputs
could be. We're learning about processes and forking.

int value;
int main(){
int pid, number = 1;
value = 2;
pid = fork();
value = value + 2;
number = number + 2;
if (pid) {
printf(" 0 %d %d \n", value, number);
waitpid(pid, NULL, 0);
}
else{
printf(" 1 %d %d \n", value, number);
}
return 0;
}

I've come up with 3 possibilities so far:

1) the fork() fails; the parent's pid is assigned a negative integer,
so the if() condition passes and the output is 0 4 3

2) the fork() succeeds, the child* (pid = 0 from successful fork())
prints 1 4 3 and then returns; the parent (pid = child's process id #)
starts up prints 0 4 3 and returns

3) the fork() succeeds, but the child's quantum expires^ before it
reaches the printf(), the parent (pid = child's process id #) starts,
prints 0 4 3 and then waits for the child; the child (pid = 0 from
successful fork()) starts back up and prints 1 4 3 and returns; the
parent returns

* I guess the child takes precedence over the parent (system
dependent?) because every time I've run the program the output has been
1 4 3 followed by 0 4 3.

^ I guess the CPU's quantum length would have to be incredibly small
for case 3 to happen, but it's possible, right?

I'm new to this material, so any comments would be truly appreciated.

Feb 5 '06 #1
Share this Question
Share on Google+
27 Replies


P: n/a
st***@stevedurkin.net wrote:
I was given the following code, and asked what the possible outputs
could be. We're learning about processes and forking.

int value;
int main(){
int pid, number = 1;
value = 2;
pid = fork();


Sorry, but fork() is not part of ISO C. Take your question to
news:comp.unix.programmer, where it will likely be answered thoroughly
and gracefully.

HTH,
--ag

--
Artie Gold -- Austin, Texas
"Topicality is important!"
Feb 5 '06 #2

P: n/a
In article <11**********************@o13g2000cwo.googlegroups .com>,
<st***@stevedurkin.net> wrote:
I was given the following code, and asked what the possible outputs
could be. We're learning about processes and forking.
fork() is not part of the C language. I suggest you take the
question to a more appropriate newsgroup, such as comp.unix.programmer

I've come up with 3 possibilities so far:


Oh, there's more than 3, especially since your program
doesn't use volatile, and your program doesn't declare printf().
It also has some POSIX problems, but POSIX is off topic for
comp.lang.c .
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton
Feb 5 '06 #3

P: n/a
st***@stevedurkin.net writes:
I was given the following code, and asked what the possible outputs
could be. We're learning about processes and forking.

int value;
int main(){
int pid, number = 1;
value = 2;
pid = fork();
value = value + 2;
number = number + 2;
if (pid) {
printf(" 0 %d %d \n", value, number);
waitpid(pid, NULL, 0);
}
else{
printf(" 1 %d %d \n", value, number);
}
return 0;
}

[snip]

"int main()" is valid, but "int main(void)" is preferred.

You're missing a "#include <stdio.h>", which is required if you're
going to use printf(). You're also missing whatever header declares
fork() and waitpid().

But in fact, the code above wouldn't even compile without a #include
for at least one of the headers that defines the NULL macro. Please
post complete, compilable programs.

The fork() function is not defined in standard C. The people who can
answer your questions about it hang out in comp.unix.programmer.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 5 '06 #4

P: n/a
# * I guess the child takes precedence over the parent (system
# dependent?) because every time I've run the program the output has been
# 1 4 3 followed by 0 4 3.

If you need to serialise code, use a language/library that
guarentees serialisation rather than hoping and guessing.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
But I do believe in this.
Feb 6 '06 #5

P: n/a
Walter Roberson wrote:
Oh, there's more than 3, especially since your program
doesn't use volatile,


why does that matter? there's no need for volatile here.

Feb 6 '06 #6

P: n/a
In article <11**********************@g47g2000cwa.googlegroups .com>,
tedu <tu@zeitbombe.org> wrote:
Walter Roberson wrote:
Oh, there's more than 3, especially since your program
doesn't use volatile,
why does that matter? there's no need for volatile here.


The original poster's program modifies both "value" and "number"
inside the forked process. The operation of fork() and the
semantics of modifying values in multiple processes are not
specified (or imagined) in the C standards. C specifies that
if a variable might be modified by mechanisms outside of C, then one
must qualify the variable with "volatile".

Without the "volatile", the C compiler is justified in loading the
variables into registers before the fork() and holding them there,
thus producing two -identical- output lines.
--
"law -- it's a commodity"
-- Andrew Ryan (The Globe and Mail, 2005/11/26)
Feb 6 '06 #7

P: n/a
On 2006-02-06, Walter Roberson <ro******@ibd.nrc-cnrc.gc.ca> wrote:
In article <11**********************@g47g2000cwa.googlegroups .com>,
tedu <tu@zeitbombe.org> wrote:
Walter Roberson wrote:
Oh, there's more than 3, especially since your program
doesn't use volatile,

why does that matter? there's no need for volatile here.


The original poster's program modifies both "value" and "number"
inside the forked process. The operation of fork() and the
semantics of modifying values in multiple processes are not
specified (or imagined) in the C standards. C specifies that
if a variable might be modified by mechanisms outside of C, then one
must qualify the variable with "volatile".


The particular outside-of-C mechanism in use does not provide for the
modification of the variable in one process by another process, so it is
not necessary. [this is the problem with off-topic responses - some of
them are inevitably wrong]
Feb 6 '06 #8

P: n/a
On Mon, 06 Feb 2006 18:56:00 +0000, Walter Roberson wrote:
In article <11**********************@g47g2000cwa.googlegroups .com>, tedu
<tu@zeitbombe.org> wrote:
Walter Roberson wrote:
Oh, there's more than 3, especially since your program doesn't use
volatile,
why does that matter? there's no need for volatile here.


The original poster's program modifies both "value" and "number" inside
the forked process. The operation of fork() and the semantics of modifying
values in multiple processes are not specified (or imagined) in the C
standards.


Having said that, surely all bets are then off? As far a standard C is
concerned, the program might do anything at all.
C specifies that if a variable might be modified by mechanisms
outside of C, then one must qualify the variable with "volatile".
To speculate any further, a meaning must be given to fork(). Taking the
POSIX version as a reasonable guess, I would not say that any variables
are being modified by any mechanism "outside of C". (Sure, the program
forks, but there is no IPC or shared memory.)
Without the "volatile", the C compiler is justified in loading the
variables into registers before the fork() and holding them there, thus
producing two -identical- output lines.


I take it you mean identical but for the leading 0/1?. If so, is that not
what happens, registers or no registers, volatile or no volatile, and,
indeed, what the OP stated initially?

--
Ben.

Feb 7 '06 #9

P: n/a
SM Ryan wrote:

# * I guess the child takes precedence over the parent (system
# dependent?) because every time I've run the program the output
# has been 1 4 3 followed by 0 4 3.

If you need to serialise code, use a language/library that
guarentees serialisation rather than hoping and guessing.


Please take this to a group where it is on-topic. Also please fix
your non-conventional quote marker character.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
Feb 7 '06 #10

P: n/a
In article <pa****************************@bsb.me.uk>,
Ben Bacarisse <be********@bsb.me.uk> wrote:
To speculate any further, a meaning must be given to fork(). Taking the
POSIX version as a reasonable guess, I would not say that any variables
are being modified by any mechanism "outside of C". (Sure, the program
forks, but there is no IPC or shared memory.)


POSIX.1 1990 section 3.1.1 "Process Creation", subsection
3.1.1.2 "Description" [of fork()], says that the child process
shall be an "exact copy of the calling process" with certain exceptions.
None of those exceptions deal with the matter of whether the variables
are shared between the resulting processes. All that is required
in that regard is,

After fork(), both the parent and the child processes shall be
capable of executing independently before either terminates.

"executing independantly" is not qualified, so it is not clear
what happens with variables. The list of exceptions about "exact copy"
makes it clear that it is permissible for the two processes to share
some characteristics (e.g., having to do with file or directory
descriptors.) There is a whole section of POSIX.1 devoted to the
issues involved in sharing file descriptors, so clearly -some-
parts of the process are shared. [Note in this regard that POSIX.1
does -not- define any manner of "threads", so the issues are
considered to arise between fork()'d processes.]

It has been some time since I went through POSIX.1 in detail;
I do not at the moment recall any section of POSIX.1 that requires
duplicating virtual memory or copy-on-write semantics for fork().
Although POSIX.1 Part 1 defines its APIs in terms of C, POSIX.1
is intended to be language-agnostic; as such it should neither
permit nor forbid the language from offering (or accidently
implementing) shared memory across forks. As C does not prohibit
sharing from happening in case of fork(), we must consider the
matter to be completely undefined behaviour when volatile is not
used, and at least -more- specified behaviour when volatile is used.
--
Prototypes are supertypes of their clones. -- maplesoft
Feb 7 '06 #11

P: n/a
On Tue, 07 Feb 2006 18:29:23 +0000, Walter Roberson wrote:
In article <pa****************************@bsb.me.uk>, Ben Bacarisse
<be********@bsb.me.uk> wrote:
To speculate any further, a meaning must be given to fork(). Taking the
POSIX version as a reasonable guess, I would not say that any variables
are being modified by any mechanism "outside of C". (Sure, the program
forks, but there is no IPC or shared memory.)


<description of fork() snipped>

As C does not prohibit sharing from happening in case of fork(), we
must consider the matter to be completely undefined behaviour when
volatile is not used, and at least -more- specified behaviour when
volatile is used.


I am having trouble with this. It suggests that any program that uses
fork() must mark *all* its variables volatile in order to avoid undefined
behaviour and even then all you get is "more" specified behaviour.

This implies that standard C does not have strong enough semantics for
programs that use POSIX fork() to have a defined meaning.

--
Ben.

Feb 8 '06 #12

P: n/a
On 2006-02-08, Ben Bacarisse <be********@bsb.me.uk> wrote:
On Tue, 07 Feb 2006 18:29:23 +0000, Walter Roberson wrote:
In article <pa****************************@bsb.me.uk>, Ben Bacarisse
<be********@bsb.me.uk> wrote:
To speculate any further, a meaning must be given to fork(). Taking the
POSIX version as a reasonable guess, I would not say that any variables
are being modified by any mechanism "outside of C". (Sure, the program
forks, but there is no IPC or shared memory.)


<description of fork() snipped>

As C does not prohibit sharing from happening in case of fork(), we
must consider the matter to be completely undefined behaviour when
volatile is not used, and at least -more- specified behaviour when
volatile is used.


I am having trouble with this. It suggests that any program that uses
fork() must mark *all* its variables volatile in order to avoid undefined
behaviour and even then all you get is "more" specified behaviour.

This implies that standard C does not have strong enough semantics for
programs that use POSIX fork() to have a defined meaning.


Well, of course it doesn't. POSIX fork() isn't provided in standard C.
Therefore standard C doesn't define the meaning of any program using
fork(). That still doesn't mean you have to mark stuff as volatile,
given what the semantics [as provided in posix] actually are.
Feb 8 '06 #13

P: n/a
In article <sl***********************@random.yi.org>,
Jordan Abel <ra*******@gmail.com> wrote:
Well, of course it doesn't. POSIX fork() isn't provided in standard C.
Therefore standard C doesn't define the meaning of any program using
fork(). That still doesn't mean you have to mark stuff as volatile,
given what the semantics [as provided in posix] actually are.


You are making a claim that the semantics of fork() "as provided in
posix" have some specific behaviour. Please cite specific sections
that establish the semantics that you believe to be "provided in
posix".

I have ISO 9945-1 / IEEE 1003.1 1990 right here, and I do not
find the semantics you impute. All I find is the wording I mentioned
before in the main description of fork() about the two processes
executing "independantly", together with some vague implications
in the "informative" (but not normative) Rationale, B.3.1.1 Process
Creation, in the description of ENOMEM.

B.3.1.1 -specifically- says that only some implementations of fork()
are capable of returning ENOMEM, so any the most one can conclude from
that discussion is that duplicating process memory is an -allowed-
result of fork() but not a -required- result of fork().

I refer you back to the wording Keith dug up in the C standard, to the
effect that "undefined behaviour includes all cases where this standard
does not specify a behaviour". Just because fork() does not result in
shared memory effects on any POSIX.1 implementation you have
encountered does not mean that there cannot be a POSIX.1 conformant
implementation in which fork() does have shared memory effects.
--
Prototypes are supertypes of their clones. -- maplesoft
Feb 8 '06 #14

P: n/a
On 2006-02-08, Walter Roberson <ro******@ibd.nrc-cnrc.gc.ca> wrote:
In article <sl***********************@random.yi.org>,
Jordan Abel <ra*******@gmail.com> wrote:
Well, of course it doesn't. POSIX fork() isn't provided in standard C.
Therefore standard C doesn't define the meaning of any program using
fork(). That still doesn't mean you have to mark stuff as volatile,
given what the semantics [as provided in posix] actually are.
You are making a claim that the semantics of fork() "as provided in
posix" have some specific behaviour. Please cite specific sections
that establish the semantics that you believe to be "provided in
posix".

I have ISO 9945-1 / IEEE 1003.1 1990 right here, and I do not
find the semantics you impute. All I find is the wording I mentioned
before in the main description of fork() about the two processes
executing "independantly", together with some vague implications
in the "informative" (but not normative) Rationale, B.3.1.1 Process
Creation, in the description of ENOMEM.


I think that if they influence each other's variables, they're hardly
independent.
B.3.1.1 -specifically- says that only some implementations of fork()
are capable of returning ENOMEM, so any the most one can conclude from
that discussion is that duplicating process memory is an -allowed-
result of fork() but not a -required- result of fork().
Rather than "returning" ENOMEM (funny thing to call it - but we all
understand "returning E?????" to mean returning an error value and
setting errno to the mentioned value), an implementation could block
both processes until memory is available. Or it could use copy-on-write
semantics (which, then, would succeed at the fork call _despite_ a
shortage of available memory), blocking or segfaulting the process when
it runs out of memory [and hoping, presumably, that the child dies or
execs before it or the parent modify a significant number of pages]
I refer you back to the wording Keith dug up in the C standard, to the
effect that "undefined behaviour includes all cases where this standard
does not specify a behaviour". Just because fork() does not result in
shared memory effects on any POSIX.1 implementation you have
encountered does not mean that there cannot be a POSIX.1 conformant
implementation in which fork() does have shared memory effects.


I believe the "independently" wording you mentioned precludes that, and
I just named two other reasons fork() could be incapable of resulting in
ENOMEM.
Feb 8 '06 #15

P: n/a
In article <ds**********@canopus.cc.umanitoba.ca>,
Walter Roberson <ro******@ibd.nrc-cnrc.gc.ca> wrote:
Just because fork() does not result in
shared memory effects on any POSIX.1 implementation you have
encountered does not mean that there cannot be a POSIX.1 conformant
implementation in which fork() does have shared memory effects.


This would not be POSIX-conformant in any sense except an absurdly
pedantic one. Everyone knows what POSIX intends here. If you find
the wording insufficiently precise, this is not the place to bring it
up.

-- Richard
Feb 8 '06 #16

P: n/a
In article <ds***********@pc-news.cogsci.ed.ac.uk>,
Richard Tobin <ri*****@cogsci.ed.ac.uk> wrote:
In article <ds**********@canopus.cc.umanitoba.ca>,
Walter Roberson <ro******@ibd.nrc-cnrc.gc.ca> wrote:
Just because fork() does not result in
shared memory effects on any POSIX.1 implementation you have
encountered does not mean that there cannot be a POSIX.1 conformant
implementation in which fork() does have shared memory effects.
This would not be POSIX-conformant in any sense except an absurdly
pedantic one. Everyone knows what POSIX intends here.


There are many discussions in comp.lang.c that revolve around
what the C standard actually -says- rather than what "everyone knows"
happens in real implementations. Just look at the DS9000 specs ;-)

The OP intended two variables to be modified by different processes,
believing that the modifications in one should result in modifications
in the other, and several of the replies were in terms of time slices
rather than in terms of "the two processes just don't share memory".
The OP -intended- intra-process interactions, and the only way within
C that one can deal with asynchronous interactions is to use volatile.
POSIX does not define "independant" execution at all clearly; either
POSIX defines that there will not be intraprocess effects (in which
case volatile becomes redundant, as does most of the program as a whole),
or else POSIX does -not- define that there will be no intraprocess effects,
in which case volatile is the only chance that one has within C
of getting the interactions right.

Having gone through POSIX.1 this morning, I don't believe that defines
the matter either way, so I disagree with Jordan that volatile is not
necessary for the program -- at least when the program is
run on the DS9003.1 series.

volatile exists for the cases where the programmer cannot promise
that variables will only be modified through overt synchronous
routines that conform to the C specifications. fork() in the
presence of possible (or at least expected) shared memory cannot
meet that promise, so the programmer, expecting that promise
to be broken, should have used volatile.
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton
Feb 8 '06 #17

P: n/a
On 2006-02-08, Walter Roberson <ro******@ibd.nrc-cnrc.gc.ca> wrote:
In article <ds***********@pc-news.cogsci.ed.ac.uk>,
Richard Tobin <ri*****@cogsci.ed.ac.uk> wrote:
In article <ds**********@canopus.cc.umanitoba.ca>,
Walter Roberson <ro******@ibd.nrc-cnrc.gc.ca> wrote:
Just because fork() does not result in
shared memory effects on any POSIX.1 implementation you have
encountered does not mean that there cannot be a POSIX.1 conformant
implementation in which fork() does have shared memory effects.
This would not be POSIX-conformant in any sense except an absurdly
pedantic one. Everyone knows what POSIX intends here.


There are many discussions in comp.lang.c that revolve around
what the C standard actually -says- rather than what "everyone knows"
happens in real implementations. Just look at the DS9000 specs ;-)

The OP intended two variables to be modified by different processes,
believing that the modifications in one should result in modifications
in the other, and several of the replies were in terms of time slices
rather than in terms of "the two processes just don't share memory".
The OP -intended- intra-process interactions, and the only way within
C that one can deal with asynchronous interactions is to use volatile.


No, the question was about the effects of "timeslices", etc, on the
_output_ of the two programs [which _do_ share an open file, namely
stdout]
Having gone through POSIX.1 this morning, I don't believe that defines
the matter either way, so I disagree with Jordan that volatile is not
necessary for the program -- at least when the program is
run on the DS9003.1 series.
But if the programmer does not INTEND that the variable in the parent
process should be modified by actions taken in the child process, it
doesn't make sense to add volatile - it might make sense to do something
else about it, but adding volatile doesn't fit the programmer's intent.
volatile exists for the cases where the programmer cannot promise
that variables will only be modified through overt synchronous
routines that conform to the C specifications. fork() in the
presence of possible (or at least expected) shared memory
You're the only one who thinks there is any wording that allows fork()
to have shared memory semantics for modifiable variables
cannot meet that promise, so the programmer, expecting that promise to
be broken, should have used volatile.

Feb 8 '06 #18

P: n/a
Walter Roberson wrote:
You are making a claim that the semantics of fork() "as provided in
posix" have some specific behaviour. Please cite specific sections
that establish the semantics that you believe to be "provided in
posix".


http://www.opengroup.org/onlinepubs/...ons/vfork.html
"The vfork() function differs from fork() only in that the child
process can share code and data with the calling process (parent
process)."

now if vfork() is different because it can share, and that is the only
difference, i think it's pretty clear that fork() cannot share.

Feb 8 '06 #19

P: n/a
"tedu" <tu@zeitbombe.org> writes:
Walter Roberson wrote:
You are making a claim that the semantics of fork() "as provided in
posix" have some specific behaviour. Please cite specific sections
that establish the semantics that you believe to be "provided in
posix".


http://www.opengroup.org/onlinepubs/...ons/vfork.html
"The vfork() function differs from fork() only in that the child
process can share code and data with the calling process (parent
process)."

now if vfork() is different because it can share, and that is the only
difference, i think it's pretty clear that fork() cannot share.


And neither fork() nor vfork() is standard C. You can discuss this in
comp.unix.programmer if you like.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 9 '06 #20

P: n/a
tedu wrote:
Walter Roberson wrote:
You are making a claim that the semantics of fork() "as provided in
posix" have some specific behaviour. Please cite specific sections
that establish the semantics that you believe to be "provided in
posix".


http://www.opengroup.org/onlinepubs/...ons/vfork.html
"The vfork() function differs from fork() only in that the child
process can share code and data with the calling process (parent
process)."

now if vfork() is different because it can share, and that is the
only difference, i think it's pretty clear that fork() cannot share.


Why is this off-topic thread continuing on c.l.c? Please find an
appropriate newsgroup. This is not it.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
Feb 9 '06 #21

P: n/a
In article <11**********************@g43g2000cwa.googlegroups .com>,
tedu <tu@zeitbombe.org> wrote:
http://www.opengroup.org/onlinepubs/...ons/vfork.html
"The vfork() function differs from fork() only in that the child
process can share code and data with the calling process (parent
process)." now if vfork() is different because it can share, and that is the only
difference, i think it's pretty clear that fork() cannot share.


vfork() is not part of POSIX.1 (IEEE 1003.1-1990), so if one is
working with C + POSIX.1 then the question still arises.

--
"law -- it's a commodity"
-- Andrew Ryan (The Globe and Mail, 2005/11/26)
Feb 9 '06 #22

P: n/a
In article <43***************@yahoo.com>,
CBFalconer <cb********@maineline.net> wrote:
tedu wrote:
Walter Roberson wrote:
You are making a claim that the semantics of fork() "as provided in
posix" have some specific behaviour. Please cite specific sections
that establish the semantics that you believe to be "provided in
posix".
now if vfork() is different because it can share, and that is the
only difference, i think it's pretty clear that fork() cannot share.
Why is this off-topic thread continuing on c.l.c? Please find an
appropriate newsgroup. This is not it.


This -is- the appropriate newsgroup.

I am upholding the comp.lang.c position, i.e., that that which is not
nailed down is not to be counted on, and that one must take the appropriate
measures in C to reduce the exposure to problems.

Others are attempting to impute behaviour to C based upon non-C
materials, but I happen to have a copy of the those materials and
demonstrated that those materials are not sufficient to specify the
effects upon C.

So this really is a comp.lang.c discussion, about the meaning and
uses of volatile.
--
If you lie to the compiler, it will get its revenge. -- Henry Spencer
Feb 9 '06 #23

P: n/a
Walter Roberson wrote:

vfork() is not part of POSIX.1 (IEEE 1003.1-1990), so if one is
working with C + POSIX.1 then the question still arises.


Please refrain from these OT posts. If you wish to continue, take it to
an appropriate newsgroup.
Brian
Feb 9 '06 #24

P: n/a
In article <45************@individual.net>,
Default User <de***********@yahoo.com> wrote:
Walter Roberson wrote:
vfork() is not part of POSIX.1 (IEEE 1003.1-1990), so if one is
working with C + POSIX.1 then the question still arises.

Please refrain from these OT posts. If you wish to continue, take it to
an appropriate newsgroup.


For the point I am making, this -is- the appropriate newsgroup.

I said, "This program attempts to use side effects mechanisms that
are outside of the control of the C implementation, and therefore
in accordance with the C standard, it needs 'volatile'." Others said
"No, this routine that is outside of the scope of C is certain not to
violate the C standards, so 'volatile' is not needed." I then had to
show that their certainty on that point was misplaced (at least in
theory).

I am, in other words, upholding the standard line in this newsgroup
that that which is not specified by C is to be considered unknown
and to be protected against as far as is possible within the C language.
If such a point is off-topic in this newsgroup, then a great deal of
the discussion in this newsgroup is also off-topic.
--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes
Feb 9 '06 #25

P: n/a
Walter Roberson wrote:

I am, in other words, upholding the standard line in this newsgroup
that that which is not specified by C is to be considered unknown
and to be protected against as far as is possible within the C
language. If such a point is off-topic in this newsgroup, then a
great deal of the discussion in this newsgroup is also off-topic.


This is pure nonsense. You've been discussing far more than that and
you know it. The proper place for ANY discussion of fork() is in
comp.unix.programmer.


Brian
Feb 9 '06 #26

P: n/a
In article <45************@individual.net>,
Default User <de***********@yahoo.com> wrote:
Walter Roberson wrote:
I am, in other words, upholding the standard line in this newsgroup
that that which is not specified by C is to be considered unknown
and to be protected against as far as is possible within the C
language. If such a point is off-topic in this newsgroup, then a
great deal of the discussion in this newsgroup is also off-topic.

This is pure nonsense. You've been discussing far more than that and
you know it.
Oddly enough, I don't "know it". I referred to other standards
only in the service of the point about C.
The proper place for ANY discussion of fork() is in
comp.unix.programmer.


And when someone asks in comp.sys.sgi.* about the details of
fork() in the SGI IRIX operating system, I should tell them that,
"Sure, that information is IRIX version specific, but you'll
have to go over to comp.unix.programmer because ..." ? You'll
have to help me out here, as I seem to be somewhat stuck on
the "because" part of that statement.

Your statement is particularily puzzling as the discussion
that you considered off-topic related to POSIX.1-1990's fork().
POSIX is the Portable Operating System Interface, and as such
encompasses more than Unix (and not all Unix are POSIX.) You are
proposing that users of non-Unix POSIX.1 compliant systems should
be relying on comp.unix.programmer for information about fork() ??
In other words, the "proper place" for the discussion of fork()
depends upon the context. For the context of the point I was
making, comp.lang.c was the proper newsgroup.
--
Okay, buzzwords only. Two syllables, tops. -- Laurie Anderson
Feb 13 '06 #27

P: n/a
Walter Roberson wrote:

In other words, the "proper place" for the discussion of fork()
depends upon the context. For the context of the point I was
making, comp.lang.c was the proper newsgroup.


No, it wasn't. You made numerous off-topic statements.

Brian

--
If televison's a babysitter, the Internet is a drunk librarian who
won't shut up.
-- Dorothy Gambrell (http://catandgirl.com)
Feb 13 '06 #28

This discussion thread is closed

Replies have been disabled for this discussion.