child exit status query

[Mike]

Hi everybody

i'm playing round with more child process code.

this is a program straight from my textbook:

void main(argv, argc)
int argc; char *argv[];
{
int wch, wpar;

if(!fork())
{
printf("child pid %d\n", getpid());
printf("enter child exit status:");
scanf("%d", &wch);
printf("child exiting\n");
_exit(wch);
}
printf("waiting for child to exit\n");
waitpid(-1, &wpar, 0);
printf("child exit status was %d\n", (wpar>>8)&0xff);
}


i'm confused, because when i run it i get

child pid 9567
enter child exit status:waiting for child to exit

and the program just hangs without giving me a chance to enter an exit
status for the child.

can anyone explain? thanks.

 

[Antoninus Twink]

i'm confused, because when i run it i get

child pid 9567
enter child exit status:waiting for child to exit

and the program just hangs without giving me a chance to enter an exit
status for the child.

All that's happening is that after the fork(), the child process happens
to be the first to execute: it displays its prompt and blocks at the
scanf() call.

Meanwhile, the parent gets scheduled; it prints its message which gets
appended to your prompt.

You should still be able to enter an exit status - just type one in and
press return!

 

[Ian Collins]

Hi everybody

i'm playing round with more child process code.

this is a program straight from my textbook:

void main(argv, argc)
int argc; char *argv[];

I'm starting to think you're taking the piss.

If you are serious, post to comp.unix.programmer. You are learning Unix
system programming, not C.

 

[Keith Thompson]

i'm playing round with more child process code. [...]
can anyone explain? thanks.

Why do you persist in posting to the wrong newsgroup?

Standard C doesn't support processes. Ask your questions in
comp.unix.programmer.

 

[Keith Thompson]

i'm playing round with more child process code.

this is a program straight from my textbook:

void main(argv, argc)
int argc; char *argv[];
{

[...]

What textbook are you using? The use of the old-style function
definition is excusable if it's a very old book; in that case, you
should get a newer one if at all possible. But the use of void as the
return type of main, though it's a common error, is harder to
understand. The "void" keyword was introduced in the 1989 ANSI C
standard -- the very same document that established the requirement
that main returns int. "void main" has *never* been correct.

(Quibble: an implementation is allowed to accept forms of main other
than the two presented in the standard -- but no implementation is
required to do so, and *all* hosted implementations must support "int
main(void)" and "int main(int argc, char *argv[])".)

 

[Default User]

Hi everybody

i'm playing round with more child process code.

This is one too many. You're either trolling, or unable to read and
comprehend. Either way, a waste of time.

You know, you hate it, but:

*plonk*




Brian

 

[Ian Collins]

i'm playing round with more child process code. [...]
can anyone explain? thanks.

Why do you persist in posting to the wrong newsgroup?

Because we've been had old boy. Best of all, old Twinky boy's been had
good a proper!

 

[Ben Bacarisse]

Hi everybody

i'm playing round with more child process code.

this is a program straight from my textbook:

void main(argv, argc)
int argc; char *argv[];

You need to get a new text-book. This style of C is at least 30 years
old and has been deprecated (ie obsolete) since the mid eighties.

I don't think it was deprecated then and it certainly was not
obsolete. Portable code had to use this style right up into the early
90s (and maybe even later). Your point is valid: it is an obsolete
style, but a 20-25 year old Unix book would have had to use it.

 

[Ian Collins]

void main(argv, argc)
int argc; char *argv[];
{

[...]

What textbook are you using? The use of the old-style function
definition is excusable if it's a very old book; in that case, you
should get a newer one if at all possible. But the use of void as the
return type of main, though it's a common error, is harder to
understand. [...]

Getting the return type of main wrong is only a nit, compared to
getting its parameters in the wrong order!

Trolls just ain't what they used to be, are they?

 

[Ben Pfaff]

void main(argv, argc)
int argc; char *argv[];
{

[...]

What textbook are you using? The use of the old-style function
definition is excusable if it's a very old book; in that case, you
should get a newer one if at all possible. But the use of void as the
return type of main, though it's a common error, is harder to
understand. [...]

Getting the return type of main wrong is only a nit, compared to
getting its parameters in the wrong order!

 

[Richard]

This is one too many. You're either trolling, or unable to read and
comprehend. Either way, a waste of time.

You know, you hate it, but:

*plonk*




Brian

Bwian, fix your signature.

Oh, and nice contribution.

 

[Richard]

i'm playing round with more child process code. [...]
can anyone explain? thanks.

Why do you persist in posting to the wrong newsgroup?

Yes, he might look for one which could have corrected/modernised his
main declaration.

What part of his post was not C?

Standard C doesn't support processes. Ask your questions in
comp.unix.programmer.

C supports processes via libraries. This is comp.lang.c. I suggest you
go to comp.lang.iso.c.

 

[Kaz Kylheku]

and the program just hangs without giving me a chance to enter an exit
status for the child.

Appears to work here:

0:flynux:/home/kaz/test$ gcc test.c
test.c: In function `main':
test.c:3: warning: return type of 'main' is not `int'
0:flynux:/home/kaz/test$ ./a.out
child pid 6245
enter child exit status:waiting for child to exit
42
child exiting
child exit status was 42
25:flynux:/home/kaz/test$


The "25" in my command prompt is the exit status of your overall program. I
get a different number on different runs, sometimes 24, and at other times 26.

That's because of your void main!

With all this fuss over a child's exit status, it's rather ironic that you
declared main to return void.

 

[Kenny McCormack]

i'm playing round with more child process code. [...]
can anyone explain? thanks.

Why do you persist in posting to the wrong newsgroup?

Standard C doesn't support processes. Ask your questions in
comp.unix.programmer.

Keith Thompson (The_Other_Keith) is a known troll.
Please ignore his rantings and ravings. Just keep on posting your
questions here, and the helpful people will do their best to help you
with your issues.

 

[Kenny McCormack]

Hi everybody

i'm playing round with more child process code.

this is a program straight from my textbook:

void main(argv, argc)
int argc; char *argv[];

I'm starting to think you're taking the piss.

If you are serious, post to comp.unix.programmer. You are learning Unix
system programming, not C.

"Ian Collins" is a known troll. Please ignore his rantings.

Your postings are completely interesting and definitely on-topic here.

 

[Keith Thompson]

Ben Bacarisse wrote:



Er, no, 1989.

Unless by "portable" you mean "back-portable to pre-ansi compilers".

Er, yes, I'm sure that's what he meant by portable.

For several years after the introduction of the ANSI C standard in
1989, it was commonly necessary to write code so it would compile with
pre-ANSI compilers, often by using lots of #ifdefs. Many of the
#ifdefs could have been avoided by writing pure pre-ANSI C code, most
of which which was still valid ANSI C code, but programmers with an
eye to the future wanted to take advantages of the nifty new features
like prototypes.

We face a similar situation today with C99, except that the new
features aren't quite as nifty and the previous standard is more
rigorously defined.

 

[Keith Thompson]

Keith Thompson wrote:
(I wrote)

Yes, me too. The /other/ meaning of portable...


I have some eggs here, perhaps you could teach me....

gd&r

Ok ... but then I fail to see why you disagreed with Ben's statement
upthread.

 

[Guest]

Ben Bacarisse wrote:



Er, no, 1989.

Unless by "portable" you mean "back-portable to pre-ansi compilers".

there were still plenty of non-ANSI compilers around
for a loong time after 1989. HP charged you extra
for an ANSI compiler.

I had to modify some K&R C just a few weeks ago.
It's still around.