Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #12449 > unrolled thread
| Started by | zemir <zemir_fp@libero.it> |
|---|---|
| First post | 2011-11-01 08:27 -0700 |
| Last post | 2011-11-02 06:11 -0700 |
| Articles | 20 on this page of 146 — 41 participants |
Back to article view | Back to comp.lang.c
I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 08:27 -0700
Re: I am learning C: a little problem with a simple source code Mark Bluemel <mark_bluemel@pobox.com> - 2011-11-01 15:49 +0000
Re: I am learning C: a little problem with a simple source code nroberts <roberts.noah@gmail.com> - 2011-11-01 08:52 -0700
Re: I am learning C: a little problem with a simple source code jt@toerring.de (Jens Thoms Toerring) - 2011-11-01 16:22 +0000
Re: I am learning C: a little problem with a simple source code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-01 09:31 -0700
Re: I am learning C: a little problem with a simple source code Ike Naar <ike@sverige.freeshell.org> - 2011-11-01 16:57 +0000
Re: I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 11:51 -0700
Re: I am learning C: a little problem with a simple source code James Kuyper <jameskuyper@verizon.net> - 2011-11-01 15:04 -0400
Re: I am learning C: a little problem with a simple source code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-01 20:21 +0000
Re: I am learning C: a little problem with a simple source code jacob navia <jacob@spamsink.net> - 2011-11-01 21:41 +0100
Re: I am learning C: a little problem with a simple source code Ian Collins <ian-news@hotmail.com> - 2011-11-02 08:06 +1300
Re: I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 13:17 -0700
Re: I am learning C: a little problem with a simple source code James Kuyper <jameskuyper@verizon.net> - 2011-11-01 16:24 -0400
Re: I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 13:27 -0700
Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2011-11-01 20:24 -0700
Re: I am learning C: a little problem with a simple source code gazelle@shell.xmission.com (Kenny McCormack) - 2011-11-02 10:24 +0000
Re: I am learning C: a little problem with a simple source code "BartC" <bc@freeuk.com> - 2011-11-02 11:04 +0000
Re: I am learning C: a little problem with a simple source code James Kuyper <jameskuyper@verizon.net> - 2011-11-02 07:41 -0400
Re: I am learning C: a little problem with a simple source code Seebs <usenet-nospam@seebs.net> - 2011-11-02 18:00 +0000
Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2011-11-02 14:06 -0700
Re: I am learning C: a little problem with a simple source code John Bode <jfbode1029@gmail.com> - 2011-11-03 15:05 -0700
Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 22:55 -0800
Re: I am learning C: a little problem with a simple source code jgk@panix.com (Joe keane) - 2012-01-26 15:59 +0000
Re: I am learning C: a little problem with a simple source code Fritz Wuehler <fritz@spamexpire-201201.rodent.frell.theremailer.net> - 2012-01-27 20:28 +0100
Re: I am learning C: a little problem with a simple source code Markus Wichmann <nullplan@gmx.net> - 2012-01-28 14:11 +0100
Re: I am learning C: a little problem with a simple source code Shao Miller <sha0.miller@gmail.com> - 2012-01-29 09:34 -0500
Re: I am learning C: a little problem with a simple source code Markus Wichmann <nullplan@gmx.net> - 2012-01-30 13:38 +0100
Re: I am learning C: a little problem with a simple source code Shao Miller <sha0.miller@gmail.com> - 2012-01-30 12:10 -0500
Re: I am learning C: a little problem with a simple source code Zoltan Kocsi <zoltan@bendor.com.au> - 2012-01-29 08:55 +1100
Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 21:48 -0800
Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 21:46 -0800
Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2012-01-31 22:30 -0800
Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-08 10:11 -0800
Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2012-03-08 13:51 -0800
Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-09 12:51 -0800
Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2012-03-09 13:36 -0800
Re: I am learning C: a little problem with a simple source code jacob navia <jacob@spamsink.net> - 2012-03-09 23:50 +0100
Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-09 15:01 -0800
Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2012-03-09 16:21 -0800
Re: I am learning C: a little problem with a simple source code gazelle@shell.xmission.com (Kenny McCormack) - 2012-03-10 00:57 +0000
Re: I am learning C: a little problem with a simple source code jacob navia <jacob@spamsink.net> - 2012-03-10 13:37 +0100
Re: I am learning C: a little problem with a simple source code gazelle@shell.xmission.com (Kenny McCormack) - 2012-03-10 13:58 +0000
Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-10 12:24 -0800
Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2012-03-10 14:16 -0800
Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-11 12:50 -0700
Re: I am learning C: a little problem with a simple source code Philip Lantz <prl@canterey.us> - 2012-03-11 00:57 -0800
Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2012-03-11 03:20 -0700
Re: I am learning C: a little problem with a simple source code Philip Lantz <prl@canterey.us> - 2012-03-12 02:10 -0700
Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2012-03-12 10:49 -0700
Re: I am learning C: a little problem with a simple source code Philip Lantz <prl@canterey.us> - 2012-03-14 01:16 -0700
Re: I am learning C: a little problem with a simple source code Robert Miles <milesrf@Usenet-News.net> - 2012-04-15 06:53 -0500
Re: I am learning C: a little problem with a simple source code Nomen Nescio <nobody@dizum.com> - 2012-04-15 19:45 +0200
Re: I am learning C: a little problem with a simple source code Philip Lantz <prl@canterey.us> - 2012-04-15 15:06 -0700
Re: I am learning C: a little problem with a simple source code 88888 Dihedral <dihedral88888@googlemail.com> - 2012-04-16 10:56 -0700
Re: I am learning C: a little problem with a simple source code Ian Collins <ian-news@hotmail.com> - 2011-11-03 10:19 +1300
Re: I am learning C: a little problem with a simple source code Seebs <usenet-nospam@seebs.net> - 2011-11-02 21:10 +0000
Re: I am learning C: a little problem with a simple source code Kaz Kylheku <kaz@kylheku.com> - 2011-11-03 05:13 +0000
Re: I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 13:29 -0700
Re: I am learning C: a little problem with a simple source code Seebs <usenet-nospam@seebs.net> - 2011-11-01 21:44 +0000
Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-03 06:33 -0700
Re: I am learning C: a little problem with a simple source code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-03 07:05 -0700
Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-03 15:32 -0700
Re: I am learning C: a little problem with a simple source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-04 01:44 -0700
Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-04 07:30 -0700
Re: I am learning C: a little problem with a simple source code John Gordon <gordon@panix.com> - 2011-11-04 16:03 +0000
Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-04 09:20 -0700
Re: I am learning C: a little problem with a simple source code John Gordon <gordon@panix.com> - 2011-11-04 16:45 +0000
Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-04 11:59 -0700
Re: I am learning C: a little problem with a simple source code John Gordon <gordon@panix.com> - 2011-11-04 19:32 +0000
Re: I am learning C: a little problem with a simple source code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-05 04:07 -0700
Re: I am learning C: a little problem with a simple source code John Gordon <gordon@panix.com> - 2011-11-04 16:54 +0000
Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-04 11:58 -0700
Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 18:25 +0100
Re: I am learning C: a little problem with a simple source code gordonb.e1fpi@burditt.org (Gordon Burditt) - 2011-11-04 13:50 -0500
Re: I am learning C: a little problem with a simple source code Pasquale Frega <zemir_fp@libero.it> - 2011-11-04 11:57 -0700
Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2011-11-04 14:44 -0700
Re: I am learning C: a little problem with a simple source code "osmium" <r124c4u102@comcast.net> - 2011-11-04 14:03 -0500
Re: I am learning C: a little problem with a simple source code Kaz Kylheku <kaz@kylheku.com> - 2011-11-04 21:37 +0000
Re: I am learning C: a little problem with a simple source code Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-06 12:20 +0200
Re: I am learning C: a little problem with a simple source code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-04 08:32 -0700
Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-04 09:04 -0700
Re: I am learning C: a little problem with a simple source code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-04 10:28 -0700
Re: I am learning C: a little problem with a simple source code Seebs <usenet-nospam@seebs.net> - 2011-11-03 18:35 +0000
Re: I am learning C: a little problem with a simple source code Pasquale Frega <zemir_fp@libero.it> - 2011-11-03 14:50 -0700
Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2011-11-03 15:59 -0700
Re: I am learning C: a little problem with a simple source code Pasquale Frega <zemir_fp@libero.it> - 2011-11-04 12:00 -0700
Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 20:58 +0100
Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 21:13 +0100
Re: I am learning C: a little problem with a simple source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-04 01:56 -0700
Re: I am learning C: a little problem with a simple source code Pasquale Frega <zemir_fp@libero.it> - 2011-11-04 12:12 -0700
Re: I am learning C: a little problem with a simple source code Ian Collins <ian-news@hotmail.com> - 2011-11-05 10:09 +1300
Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-03 15:32 -0700
Re: I am learning C: a little problem with a simple source code Seebs <usenet-nospam@seebs.net> - 2011-11-03 22:53 +0000
Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-03 17:57 -0700
Re: I am learning C: a little problem with a simple source code Robert Wessel <robertwessel2@yahoo.com> - 2011-11-03 21:35 -0500
Re: I am learning C: a little problem with a simple source code Seebs <usenet-nospam@seebs.net> - 2011-11-04 03:31 +0000
Re: I am learning C: a little problem with a simple source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-04 02:25 -0700
Re: I am learning C: a little problem with a simple source code Kulin Remailer <remailer@reece.net.au> - 2011-11-03 22:47 +0000
Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-03 16:14 -0700
Re: I am learning C: a little problem with a simple source code Robert Wessel <robertwessel2@yahoo.com> - 2011-11-03 21:55 -0500
Re: I am learning C: a little problem with a simple source code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-04 08:10 -0700
Re: I am learning C: a little problem with a simple source code ImpalerCore <jadill33@gmail.com> - 2011-11-04 14:21 -0700
Re: I am learning C: a little problem with a simple source code Robert Wessel <robertwessel2@yahoo.com> - 2011-11-04 16:31 -0500
Re: I am learning C: a little problem with a simple source code Ian Collins <ian-news@hotmail.com> - 2011-11-05 10:41 +1300
Re: I am learning C: a little problem with a simple source code Seebs <usenet-nospam@seebs.net> - 2011-11-04 21:38 +0000
Re: I am learning C: a little problem with a simple source code Robert Wessel <robertwessel2@yahoo.com> - 2011-11-04 22:18 -0500
Re: I am learning C: a little problem with a simple source code Lew Pitcher <lpitcher@teksavvy.com> - 2011-11-05 11:11 -0400
Re: I am learning C: a little problem with a simple source code Lew Pitcher <lpitcher@teksavvy.com> - 2011-11-05 11:13 -0400
Re: I am learning C: a little problem with a simple source code Robert Wessel <robertwessel2@yahoo.com> - 2011-11-05 23:35 -0500
Re: I am learning C: a little problem with a simple source code Seebs <usenet-nospam@seebs.net> - 2011-11-06 07:40 +0000
Re: I am learning C: a little problem with a simple source code James Kuyper <jameskuyper@verizon.net> - 2011-11-04 18:15 -0400
Re: I am learning C: a little problem with a simple source code ImpalerCore <jadill33@gmail.com> - 2011-11-04 20:00 -0700
Re: I am learning C: a little problem with a simple source code James Kuyper <jameskuyper@verizon.net> - 2011-11-04 23:19 -0400
Re: I am learning C: a little problem with a simple source code ImpalerCore <jadill33@gmail.com> - 2011-11-04 20:33 -0700
Re: I am learning C: a little problem with a simple source code Kaz Kylheku <kaz@kylheku.com> - 2011-11-05 03:52 +0000
Re: I am learning C: a little problem with a simple source code Ian Collins <ian-news@hotmail.com> - 2011-11-05 17:01 +1300
Re: I am learning C: a little problem with a simple source code ImpalerCore <jadill33@gmail.com> - 2011-11-04 21:48 -0700
Re: I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 13:19 -0700
Re: I am learning C: a little problem with a simple source code Ian Collins <ian-news@hotmail.com> - 2011-11-02 09:26 +1300
Re: I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 13:23 -0700
Re: I am learning C: a little problem with a simple source code Ian Collins <ian-news@hotmail.com> - 2011-11-02 09:27 +1300
Re: I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 13:31 -0700
Re: I am learning C: a little problem with a simple source code jt@toerring.de (Jens Thoms Toerring) - 2011-11-01 22:48 +0000
Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 23:09 -0800
Re: I am learning C: a little problem with a simple source code gordonb.prbii@burditt.org (Gordon Burditt) - 2011-11-01 21:24 -0500
Re: I am learning C: a little problem with a simple source code Dann Corbit <dcorbit@connx.com> - 2011-11-02 21:03 -0700
Re: I am learning C: a little problem with a simple source code Ike Naar <ike@sverige.freeshell.org> - 2011-11-03 06:39 +0000
Re: I am learning C: a little problem with a simple source code Barry Schwarz <schwarzb@dqel.com> - 2011-11-03 18:33 -0700
Re: I am learning C: a little problem with a simple source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-04 03:03 -0700
Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 11:40 +0100
Re: I am learning C: a little problem with a simple source code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-04 11:36 +0000
Re: I am learning C: a little problem with a simple source code Kaz Kylheku <kaz@kylheku.com> - 2011-11-04 15:58 +0000
Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 07:24 +0100
Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 10:28 +0100
Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 16:02 +0100
Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 16:20 +0100
Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 16:39 +0100
Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-06 18:07 +0100
Re: I am learning C: a little problem with a simple source code Barry Schwarz <schwarzb@dqel.com> - 2011-11-06 09:59 -0800
Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-06 19:23 +0100
Re: I am learning C: a little problem with a simple source code James Kuyper <jameskuyper@verizon.net> - 2011-11-06 15:23 -0500
Re: I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 11:52 -0700
Re: I am learning C: a little problem with a simple source code "BartC" <bc@freeuk.com> - 2011-11-01 23:02 +0000
Re: I am learning C: a little problem with a simple source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-02 03:53 -0700
Re: I am learning C: a little problem with a simple source code James Kuyper <jameskuyper@verizon.net> - 2011-11-02 08:03 -0400
Re: I am learning C: a little problem with a simple source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-02 06:11 -0700
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-11-03 07:05 -0700 |
| Message-ID | <83215575-680c-4f2a-8b95-f31fca278e83@u28g2000yqb.googlegroups.com> |
| In reply to | #12583 |
On Nov 3, 3:33 pm, Bill Reid <hormelf...@gmail.com> wrote: > > Oh yes, people could die...soooooooo, please explain how a > common OS, such as say, Windows(TM), uses the return value > from main()? Or for that matter, a TRUE Unix(TM)? Or any > other OSs that you are an expert on? > You return 0 to indicate that the program exited normally, and EXIT_FAILURE to indicate that it encountered some sort of error condition. Many OSes allow scripts or other programs to use these values, to indicate whether a program did what was intended or not. -- Fuzzy Logic Trees, decision trees that allow for a "maybe". http://www.malcolmmclean.site11.com/www
[toc] | [prev] | [next] | [standalone]
| From | Bill Reid <hormelfree@gmail.com> |
|---|---|
| Date | 2011-11-03 15:32 -0700 |
| Message-ID | <8df3d992-1936-4e17-85c2-8e403a32238f@s30g2000yqd.googlegroups.com> |
| In reply to | #12585 |
n Nov 3, 7:05 am, Malcolm McLean <malcolm.mcle...@btinternet.com> wrote: > On Nov 3, 3:33 pm, Bill Reid <hormelf...@gmail.com> wrote: > > > Oh yes, people could die...soooooooo, please explain how a > > common OS, such as say, Windows(TM), uses the return value > > from main()? Or for that matter, a TRUE Unix(TM)? Or any > > other OSs that you are an expert on? > > You return 0 to indicate that the program exited normally, and > EXIT_FAILURE to indicate that it encountered some sort of error > condition. > Objection, motion to strike, non-responsive... > Many OSes allow scripts or other programs to use these values, to > indicate whether a program did what was intended or not. > OK, that's a little better, although an OS "allow"ing a script that does something undefined and unknowable is not the same thing as the OS doing something with the value...and you snipped out my other pertinent question and either deliberately or otherwise misunderstood it, you know, the thing about WHY you would set either "EXIT_SUCCESS" or "EXIT_FAILURE" from main(); maybe the other "computer expert" can answer that one better... --- William Ernest Reid
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-11-04 01:44 -0700 |
| Message-ID | <d0a66b2b-6540-432f-9b2e-b342b5123e62@x8g2000yql.googlegroups.com> |
| In reply to | #12636 |
On Nov 3, 10:32 pm, Bill Reid <hormelf...@gmail.com> wrote: > n Nov 3, 7:05 am, Malcolm McLean <malcolm.mcle...@btinternet.com> > wrote:> On Nov 3, 3:33 pm, Bill Reid <hormelf...@gmail.com> wrote: > > > Oh yes, people could die...soooooooo, some people actually work on systems were incorrect operation of the software *could* kill someone. Even Blackberry servers going out for a day or two can cause massive inconvenience. Hopefully you don't work on anything like that... > > > please explain how a > > > common OS, such as say, Windows(TM), uses the return value > > > from main()? Or for that matter, a TRUE Unix(TM)? Or any > > > other OSs that you are an expert on? > > > You return 0 to indicate that the program exited normally, and > > EXIT_FAILURE to indicate that it encountered some sort of error > > condition. > > Objection, motion to strike, non-responsive... I'm sorry? Q: "explain how an OS uses the return value from main()" A: "a value of 0 indicates success and EXIT_FAILURE indicates failure" That's about all the standard can say. On Unix the value returned can be used by the parent process, for instance a shell script to detect success or failure. VMS used to output an error message in a standard format for that OS. > > Many OSes allow scripts or other programs to use these values, to > > indicate whether a program did what was intended or not. so you stuck your snarky answer in the middle of his respose for... jollies? > OK, that's a little better, although an OS "allow"ing > a script that does something undefined and unknowable > is not the same thing as the OS doing something with > the value... your point being? > and you snipped out my other pertinent question > and either deliberately or otherwise misunderstood it, you > know, the thing about WHY you would set either "EXIT_SUCCESS" > or "EXIT_FAILURE" from main(); you set the value to EXIT_SUCCESS for success and to EXIT_FAILURE for failure. presumably you know enough about the application domian domain you are programming for to judge if something has succeeded or not. > maybe the other "computer > expert" can answer that one better... expert: one who used to be a spurt spurt: a drip under pressure
[toc] | [prev] | [next] | [standalone]
| From | Bill Reid <hormelfree@gmail.com> |
|---|---|
| Date | 2011-11-04 07:30 -0700 |
| Message-ID | <7f115361-afe4-44ac-aad5-1e0052dd3082@9g2000yqv.googlegroups.com> |
| In reply to | #12664 |
On Nov 4, 1:44 am, Nick Keighley <nick_keighley_nos...@hotmail.com> wrote: > On Nov 3, 10:32 pm, Bill Reid <hormelf...@gmail.com> wrote: > > > n Nov 3, 7:05 am, Malcolm McLean <malcolm.mcle...@btinternet.com> > > wrote:> On Nov 3, 3:33 pm, Bill Reid <hormelf...@gmail.com> wrote: > > > > Oh yes, people could die...soooooooo, > > some people actually work on systems were incorrect operation of the > software *could* kill someone. > Yes, so what does that have to do with the return value of main()? That was the question, can you think of a single case where somebody died as a result of an incorrect return value of main()? Can you even come up with a far-fetched hypothetical (primarily for amusement value, of course)? I mean, more people have died of the flu because somebody spit on the sidewalk, and by "more" I mean maybe a 0.3% chance of one person in the history of the world... > Even Blackberry servers going out for a day or two can cause massive > inconvenience. Hopefully you don't work on anything like that... > No, my software works, other "professional programmers" write the crap that fails me on a regular basis...some of which probably post here about people dying as the result of the return value of main() (that type of illogic COULD be deadly when applied to "life-critical" applications). > > > > please explain how a > > > > common OS, such as say, Windows(TM), uses the return value > > > > from main()? Or for that matter, a TRUE Unix(TM)? Or any > > > > other OSs that you are an expert on? > > > > You return 0 to indicate that the program exited normally, and > > > EXIT_FAILURE to indicate that it encountered some sort of error > > > condition. > > > Objection, motion to strike, non-responsive... > > I'm sorry? > > Q: "explain how an OS uses the return value from main()" > A: "a value of 0 indicates success and EXIT_FAILURE indicates failure" > Q: Could you explain how a doctor uses a Magic 8-Ball? A: A value of "outlook uncertain" indicates "outlook uncertain"... > That's about all the standard can say. Sooooo...you don't have a reasonable point either...great... > On Unix the value returned can > be used by the parent process, for instance a shell script to detect > success or failure. Great, that's an actual answer, now we've established something, it was like pulling teeth to get to this simple point, but there it is: if you write very simple C programs that perform a single function, if the program fails to complete that function for any reason, you know what to do, in the anticipation that the program will be used in a shell script. Soooooo...is that it? Anything else to add? Anything to say about a much more complex program where this binary return value and use in a script wouldn't be of much use or sense? > > > > Many OSes allow scripts or other programs to use these values, to > > > indicate whether a program did what was intended or not. > OK. > so you stuck your snarky answer in the middle of his respose for... > jollies? > He begged the question for...well, being dense, defensive, or what? > > OK, that's a little better, although an OS "allow"ing > > a script that does something undefined and unknowable > > is not the same thing as the OS doing something with > > the value... > > your point being? > I asked specifically about the OS, but I can accept the simple script explanation...still am having trouble understanding how anybody is going to die as a PROXIMATE FORESEEABLE result of an incorrect return value of main()... > > and you snipped out my other pertinent question > > and either deliberately or otherwise misunderstood it, you > > know, the thing about WHY you would set either "EXIT_SUCCESS" > > or "EXIT_FAILURE" from main(); > > you set the value to EXIT_SUCCESS for success and to EXIT_FAILURE for > failure. YOUR HONOR, THE WITNESS IS REFUSING TO ANSWER HOW DOCTORS USE MAGIC 8-BALLS!!! > presumably you know enough about the application domian > domain you are programming for to judge if something has succeeded or > not. > Yup, as it turns out, I DID know that, I was just wondering if you did...but that's "outlook uncertain"... --- William Ernest Reid
[toc] | [prev] | [next] | [standalone]
| From | John Gordon <gordon@panix.com> |
|---|---|
| Date | 2011-11-04 16:03 +0000 |
| Message-ID | <j912bt$a1d$1@reader1.panix.com> |
| In reply to | #12676 |
In <7f115361-afe4-44ac-aad5-1e0052dd3082@9g2000yqv.googlegroups.com> Bill Reid <hormelfree@gmail.com> writes:
> That was the question, can you think of a single case where somebody
> died as a result of an incorrect return value of main()? Can you
That's a very low-level detail, unlikely to be known by anyone who wasn't
directly involved in such an incident. Asking for such information seems
dishonest.
> even come up with a far-fetched hypothetical (primarily for amusement
> value, of course)?
Imagine a medical device that emits radiation for treatment of cancer.
Imagine that the device determines the amount of radiation to be emitted
by calling a program and inspecting the exit value. One day the called
program exits with an incorrect value and the device emits too much
radiation, killing a patient.
--
John Gordon A is for Amy, who fell down the stairs
gordon@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"
[toc] | [prev] | [next] | [standalone]
| From | Bill Reid <hormelfree@gmail.com> |
|---|---|
| Date | 2011-11-04 09:20 -0700 |
| Message-ID | <7fcf604f-f62a-4c9b-b54d-d0dd05236c93@x8g2000yql.googlegroups.com> |
| In reply to | #12689 |
On Nov 4, 9:03 am, John Gordon <gor...@panix.com> wrote: > In <7f115361-afe4-44ac-aad5-1e0052dd3...@9g2000yqv.googlegroups.com> Bill Reid <hormelf...@gmail.com> writes: > > > That was the question, can you think of a single case where somebody > > died as a result of an incorrect return value of main()? Can you > > That's a very low-level detail, unlikely to be known by anyone who wasn't > directly involved in such an incident. That's a detail that would be well and fully hashed out in a wrongful death/malpractice suit, IN PUBLIC COURT... > Asking for such information seems > dishonest. > Not to mention immoral and fattening...no honest decent person would ever inquire about the exact causes of another person's death, it's just unseemly...autopsies and coroner's reports should be banned, FREE THE HONORABLE CONRAD MURRAY!!! Sheesh... > > even come up with a far-fetched hypothetical (primarily for amusement > > value, of course)? > > Imagine a medical device that emits radiation for treatment of cancer. > Imagine that the device determines the amount of radiation to be emitted > by calling a program and inspecting the exit value. One day the called > program exits with an incorrect value and the device emits too much > radiation, killing a patient. > Well, it's a little amusing, I give you that, but mostly just sad, like thinking it's "dishonest" to investigate the cause of a person's death. What I keep coming away with from this group is how completely, totally, and absolutely irrational and illogical the regular posters are; what's really scary is if you think that the poster might actually try to implement a safe radiological machine as described above... --- William Ernest Reid
[toc] | [prev] | [next] | [standalone]
| From | John Gordon <gordon@panix.com> |
|---|---|
| Date | 2011-11-04 16:45 +0000 |
| Message-ID | <j914rl$rlo$1@reader1.panix.com> |
| In reply to | #12693 |
In <7fcf604f-f62a-4c9b-b54d-d0dd05236c93@x8g2000yql.googlegroups.com> Bill Reid <hormelfree@gmail.com> writes:
> > > That was the question, can you think of a single case where somebody
> > > died as a result of an incorrect return value of main()? =A0Can you
> >
> > That's a very low-level detail, unlikely to be known by anyone who wasn't
> > directly involved in such an incident.
> That's a detail that would be well and fully hashed out in
> a wrongful death/malpractice suit, IN PUBLIC COURT...
Courts are going to care that a program failed specifically due to an
erroneous return value from main(), and not any of the other million
ways a program can fail?
Since you put such stock in this information being public, please be so
kind as to supply a few examples.
> > Asking for such information seems
> > dishonest.
> >
> Not to mention immoral and fattening...no honest decent person
> would ever inquire about the exact causes of another person's
> death, it's just unseemly...autopsies and coroner's reports
> should be banned, FREE THE HONORABLE CONRAD MURRAY!!!
Sigh.
--
John Gordon A is for Amy, who fell down the stairs
gordon@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"
[toc] | [prev] | [next] | [standalone]
| From | Bill Reid <hormelfree@gmail.com> |
|---|---|
| Date | 2011-11-04 11:59 -0700 |
| Message-ID | <a061b8d1-2777-4dde-8f33-35dbd1caa984@w7g2000yqc.googlegroups.com> |
| In reply to | #12698 |
On Nov 4, 9:45 am, John Gordon <gor...@panix.com> wrote: > In <7fcf604f-f62a-4c9b-b54d-d0dd05236...@x8g2000yql.googlegroups.com> Bill Reid <hormelf...@gmail.com> writes: > > > > > That was the question, can you think of a single case where somebody > > > > died as a result of an incorrect return value of main()? > > > > That's a very low-level detail, unlikely to be known by anyone who wasn't > > > directly involved in such an incident. > > That's a detail that would be well and fully hashed out in > > a wrongful death/malpractice suit, IN PUBLIC COURT... > > Courts are going to care that a program failed specifically due to an > erroneous return value from main(), and not any of the other million > ways a program can fail? > Well, as always, thank you for making my point for me, though I had to "trick" you into it by posting a simple fact in plain sight... Yes, a court is going to be very rigorous in assigning BLAME for a wrongful death (or in the current high-profile Conrad Murray case, involuntary manslaughter due to criminal negligence). In all the goofy attempts to "prove" that an incorrect main() return value can kill people, the goofballs have relied on somebody NEGLIGENTLY grabbing some little piece of software bascially at random and sticking it willy-nilly into a script and/or system, then expressing mock amazement when it doesn't do what it was never warranted to do, and hundreds/thousands/millions/billions of imaginary people died as a result. (My goofball example was that NORAD uses a "Hello World" program to determine whether to launch nuclear missiles; hey, "Hello World" printed successfully, but the program returns EXIT_FAILURE, LAUNCH!!!) Obviously, the people at fault would be the goofballs who just grabbed some piece of software and ASSUMED it would work a certain way. On the other hand, if there were WELL-DEFINED requirements for the operation of the software that were not met by a sub-contractor, the sub would be at least partially to blame (there might be a whole bunch of legal haggling over what responsibility the prime contractor had for acceptance testing, but in the fracas you better believe every single line of offending code and the respective contracts would be hashed over). And all of that is exactly what I said is missing, WELL-DEFINED requirements that the value be set one way or the other for the great range of programs that may be written in "C", making EXPECTATIONS and thus RESPONSIBILITY for any particular value under any particular condition moot. Now when I TELL you that I would/have only set EXIT_FAILURE for the great majority of programs I have written for some type of uncorrectable memory allocation or similar error, you are WASTING MY TIME, YOUR PRESUMABLY WORTHLESS LIFE, AND POSSIBLY THE LIFE OF SOME INNOCENT PERSON WHO IS THE VICTIM OF YOUR INSANE ASSUMPTIONS CONTRARY TO MY WELL-DEFINED ASSERTIONS if you try to argue with me about my choice, or write some stupid unauthorized script using my program. > Since you put such stock in this information being public, please be so > kind as to supply a few examples. > Anybody who has been following the Conrad Murray trial is now an expert on EVERY aspect of various anesthetic and sedative drugs, so why would you make me go out and gather for you the evidence presented in numerous lawsuits involving software (some of which I am personally aware of)? Suffice it to say, all of that kind of stuff is boring and tedious to the max... > > > Asking for such information seems > > > dishonest. > > > Not to mention immoral and fattening...no honest decent person > > would ever inquire about the exact causes of another person's > > death, it's just unseemly...autopsies and coroner's reports > > should be banned, FREE THE HONORABLE CONRAD MURRAY!!! > > Sigh. > What are you saying, you reject the findings of the defense expert regarding the levels of unmetabolized propofol in Michael Jackson's urine at autopsy as being inconsistent with the prosecution theory of a infusion drip over several hours based on the nuclear residue testing in a 1988 study of volunteers receiving a sedative level dosage of propofol? I will admit on re-direct the prosecution expert kind of demolished his testimony... But yeah, you're right, they never get into trivial little technical details in courts... --- William Ernest Reid
[toc] | [prev] | [next] | [standalone]
| From | John Gordon <gordon@panix.com> |
|---|---|
| Date | 2011-11-04 19:32 +0000 |
| Message-ID | <j91ekj$hru$1@reader1.panix.com> |
| In reply to | #12712 |
In <a061b8d1-2777-4dde-8f33-35dbd1caa984@w7g2000yqc.googlegroups.com> Bill Reid <hormelfree@gmail.com> writes:
> > Courts are going to care that a program failed specifically due to an
> > erroneous return value from main(), and not any of the other million
> > ways a program can fail?
> Yes, a court is going to be very rigorous in assigning BLAME
> for a wrongful death (or in the current high-profile Conrad
> Murray case, involuntary manslaughter due to criminal negligence).
Once the court has determined that the machine had a programming fault
which caused the death, and it it known who was responsible for said
programming fault, the court has enough data to assign blame.
However, you appear to be claiming that the court will go further and will
want to classify the particular nature of the programming fault, i.e.
whether it was an incorrect return value from main, or a floating point
conversion error, or a buffer overrun, or one of many other kinds of
technical errors.
I can't imagine the court would care about that level of detail, as it
makes no difference in the case. The court already knows who is at fault:
MegaMedicalDevicesCorp, the developer and manufacturer of the machine.
> > Sigh.
> >
> What are you saying, you reject the findings of the
> defense expert regarding the levels of unmetabolized
> propofol in Michael Jackson's urine at autopsy as being
I'm saying that in a fair debate (which is the type I hope we are having),
asking for information which your opponent cannot reasonably know seems
dishonest.
In my opinion, when you asked for specific case details "... where somebody
died as a result of an incorrect return value of main()", you were asking
the impossible. Who would know that sort of detail, aside from someone
actually involved with such an incident? Nobody.
--
John Gordon A is for Amy, who fell down the stairs
gordon@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-11-05 04:07 -0700 |
| Message-ID | <d6915625-ff6a-4785-be2d-89733dbe0a02@gk10g2000vbb.googlegroups.com> |
| In reply to | #12712 |
On Nov 4, 8:59 pm, Bill Reid <hormelf...@gmail.com> wrote: > > In all the goofy attempts to "prove" that an incorrect > main() return value can kill people, the goofballs have > relied on somebody NEGLIGENTLY grabbing some little > piece of software bascially at random and sticking it > willy-nilly into a script and/or system, then expressing > mock amazement when it doesn't do what it was never warranted > to do, and hundreds/thousands/millions/billions of > imaginary people died as a result. (My goofball example > was that NORAD uses a "Hello World" program to determine > whether to launch nuclear missiles; hey, "Hello World" > printed successfully, but the program returns EXIT_FAILURE, > LAUNCH!!!) > If you have a safety-critical program, then you have belt, braces and underpants. void main() may snap the belt - someone grabs a little utility and assumes that it will return a failure condition if it doesn't succeed. However the braces should work - he passes the code to a fellow programmer, who checks it. But maybe the documentation for the program is missing, it's Friday night, the pub is beckoning. We've still got the underpants - QA will throw a full test suite at the script, and ensure that every line is executed at least once. So it should pick up that the error condition can never be triggered. But once we're down to the underpants, we're in a very uncomfortable position. QA will rightly ask how a potentially lethal script came so close to shipping. -- Basic Algorithms: how does pow() work? Understand the math library from the ground up. htp://www.malcolmmclean.site11.com/www
[toc] | [prev] | [next] | [standalone]
| From | John Gordon <gordon@panix.com> |
|---|---|
| Date | 2011-11-04 16:54 +0000 |
| Message-ID | <j915c5$k2l$1@reader1.panix.com> |
| In reply to | #12693 |
In <7fcf604f-f62a-4c9b-b54d-d0dd05236c93@x8g2000yql.googlegroups.com> Bill Reid <hormelfree@gmail.com> writes:
> What I keep coming away with from this group is how completely,
> totally, and absolutely irrational and illogical the regular posters
> are; what's really scary is if you think that the poster might
> actually try to implement a safe radiological machine as described
> above...
You explicitly asked for a "far-fetched hypothetical" example.
I gave you one.
You criticised it for being "scary" and unsafe.
Who is being irrational and illogical here?
--
John Gordon A is for Amy, who fell down the stairs
gordon@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"
[toc] | [prev] | [next] | [standalone]
| From | Bill Reid <hormelfree@gmail.com> |
|---|---|
| Date | 2011-11-04 11:58 -0700 |
| Message-ID | <fdeec774-d878-421a-ad57-af9d64fba771@g7g2000vbv.googlegroups.com> |
| In reply to | #12700 |
On Nov 4, 9:54 am, John Gordon <gor...@panix.com> wrote: > In <7fcf604f-f62a-4c9b-b54d-d0dd05236...@x8g2000yql.googlegroups.com> Bill Reid <hormelf...@gmail.com> writes: > > > What I keep coming away with from this group is how completely, > > totally, and absolutely irrational and illogical the regular posters > > are; what's really scary is if you think that the poster might > > actually try to implement a safe radiological machine as described > > above... > > You explicitly asked for a "far-fetched hypothetical" example. > I also explicitly said I only wanted it to laugh at... > I gave you one. > You took the bait...SUCKER!!! > You criticised it for being "scary" and unsafe. > Thanks for playing... > Who is being irrational and illogical here? > Obviously the person who is so desperate to prove the unprovable they come up with laughably silly hypothetical on a direct command to provide it for comedy value... --- William Ernest Reid
[toc] | [prev] | [next] | [standalone]
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2011-11-04 18:25 +0100 |
| Message-ID | <4eb41f3e$0$1389$4fafbaef@reader2.news.tin.it> |
| In reply to | #12689 |
"John Gordon" <gordon@panix.com> ha scritto nel messaggio news:j912bt$a1d$1@reader1.panix.com... > In <7f115361-afe4-44ac-aad5-1e0052dd3082@9g2000yqv.googlegroups.com> Bill Reid > <hormelfree@gmail.com> writes: > >> That was the question, can you think of a single case where somebody >> died as a result of an incorrect return value of main()? Can you > > That's a very low-level detail, unlikely to be known by anyone who wasn't > directly involved in such an incident. Asking for such information seems > dishonest. > >> even come up with a far-fetched hypothetical (primarily for amusement >> value, of course)? > > Imagine a medical device that emits radiation for treatment of cancer. > Imagine that the device determines the amount of radiation to be emitted > by calling a program and inspecting the exit value. i think above is not ok in the case program call some extern library (or OS api) that for some reason abort() or exit() [or crash] i not be secure if possibly program "return 0" in case of crash so what is the safe solution? if two programs has to comunicate one result each other what is the safe way? i don't know! i had one comunication problem some time ago for 2 programs; the only way i try is using internet tcp address, i have 2 programs one that has the apparence of windows program[client] the other that has apparence of dos program[server] that comunicate in the same pc using a tcp port and some password [if i remember well] etc for the comunication; they seem ok. than if these programs are not in the same machine i think they can continue to comunicate and the program can run in 2 different pc or the server can comunicate to many different windwos programs in different pcs so this way to see is very good [if someone not see the security problems...] > One day the called > program exits with an incorrect value and the device emits too much > radiation, killing a patient. > > -- > John Gordon A is for Amy, who fell down the stairs > gordon@panix.com B is for Basil, assaulted by bears > -- Edward Gorey, "The Gashlycrumb Tinies" >
[toc] | [prev] | [next] | [standalone]
| From | gordonb.e1fpi@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2011-11-04 13:50 -0500 |
| Message-ID | <2aednaX5Rs5srinTnZ2dnUVZ_rmdnZ2d@posted.internetamerica> |
| In reply to | #12676 |
>> Q: "explain how an OS uses the return value from main()" >> A: "a value of 0 indicates success and EXIT_FAILURE indicates failure" *For further details, consult the documentation of the program you are running.* In a very real sense, the OS doesn't *use* the return value from main() much (although it might log it). It provides the information to applications, so *applications* can use it. The applications generally know what they are invoking, and can use program-specific knowledge of what the program they are invoking does (and they need similar knowledge to correctly invoke the program in the first place). I am taking a somewhat narrower view of "OS" and a wider view of "applications" than some may be used to. The kernel, command interpreters, and such are included, but program development software like compilers isn't, even if it comes with the OS distribution. For many programs the binary SUCCESS/FAILURE return is useful. One that uses it extensively is "make": it stops a program build if a step fails. There is a syntax to avoid the abort, if desired, for specific commands. Compilers, assemblers, linkers, etc. return an appropriate values. GCC's -Werror option lets you decide to stop builds on warnings if compiling from "make". If a program *aborts*, say by calling abort(), segmentation violation, manually being killed, or being interrupted with a character typed from the keyboard (e.g. ^C), etc., it is given an exit status which is treated as a failure, so it may still be useful to test the status even if the program never does exit(EXIT_FAILURE). Shells use this so they (not the program that crashed) can print "Segmentation violation" when it happens. There are also a bunch of little UNIX shell commands like test, expr, etc. whose primary function is to test something and set the return code accordingly, so shell scripts can do conditional testing. This is one thing that makes shell scripts powerful. Shells make the return code available to shell scripts, which can use it to take action to notify of failures or recover from them. Program termination codes go back at least as far as OS/360 JCL, where "error" status from a compiler indicated that you shouldn't bother trying to link the resulting object code (if any was produced). It's unfortunate that UNIX really only had one standard "success" value. For example, there are a number of "file compare" programs (cmp, diff, rcsdiff, etc.) which are usable from shell scripts and other programs that want to give one of 3 possible results: files compare equal (0) files compare unequal (1) comparison failed (e.g. file does not exist, permission denied, i/o error, etc.) (2) where the first two are really two different kinds of "success", but you can't indicate that, so "files unequal" is treated as a different subtype of failure. File search programs like "grep" and family also use this return code pattern (match found / no match found / problems scanning file). I have sometimes wished for two different symbols: EXIT_SUCCESS_WITH_PROMOTION_AND_RAISE and EXIT_SUCCESS_YOU_GET_TO_KEEP_YOUR_JOB_ANOTHER_WEEK which denote two different levels of "success". Many programs will report obvious failures to do what was requested with EXIT_FAILURE if the OS returns errors like I/O error, permission error, file does not exist, out of memory, out of disk space, etc., and it wasn't able to work around it. Testing the return status of a "file copy" program should provide an indication of whether it worked or not, to the extent that the OS reports problems back to the program. Programs that need more complex status returned to their invoker can go beyond the C standard and use the POSIX guarantee of being able to return 0 - 255. (Other programs have been known to use standard output or standard error, which the invoker redirects and parses). Return codes are not a substitute for error messages giving specific detail (like the name of the file the operation failed on, what operation was attempted, and what error you got). There is a whole include file, <sysexits.h> (not specified by any standard as far as I know, and used extensively by Sendmail), full of exit return codes for *MAIL TRANSPORT PROGRAMS*. Mail transport programs try to deliver mail using various methods and use specific exit codes (forms of failure) beyond those specified by the C standard, and programs that call them can either treat any value not equal to 0 or EXIT_SUCCESS as a failure, or they can use specific knowledge of the failure type to determine remedial action (for example, retrying the exact same request again later is highly appropriate for some error classes and pointless for others). The return codes in <sysexits.h> might be stretched to deal with some other network-oriented program but they are not useful for programs in general. Some examples: EX_NOHOST - the host specified did not exist. EX_NOUSER - the user specified did not exist. EX_USAGE - the command was used incorrectly, e.g. with the wrong number of arguments, a bad flag, or bad syntax. EX_TEMPFAIL - a temporary failure, such as not being able to create a network connection, and the request should be retried. EX_OSFILE - some system file does not exist, cannot be opened, or has some sort of error. EX_IOERR - An error occurred while doing I/O on some file. > Soooooo...is that it? Anything else to add? Anything to say > about a much more complex program where this binary return value > and use in a script wouldn't be of much use or sense? It's impossible to come up with a useful set of universal exit codes. Programs have too much variety. A program "identifylanguage" given a text file might use exit(54) to mean "Vietnamese". Also, any blatantly obvious success condition (like "file *DOES* exist") can be a fatal error. Beyond the class of "success" or "failure", code meanings will be individual by program (or perhaps group of similar programs) if you want to use under 128 bits for an exit code. A hopelessly interactive program (such as an editor) should report errors to the user via stderr (or a window pop-up, or whatever) instead of exiting, although having an editor being fed a script report blatant problems like not being able to open or save files or running out of memory or disk space via return code (in addition to an error message) is useful. A co-worker once decided (well before C89) that a program that dropped off the end of main() should return 0, rather than random status. Unfortunately, the unauthorized and untested change he made also had the effect that "return N;" in main() also returned 0. The change he made affected the cross-compiler, meaning it would return successful status for anything it tried to compile whether it worked or not. Someone introduced a typo into a critical part of the C library for the target system. The result: an overnight build which *apparently* succeeded, (as opposed to a build which should have died in half an hour) yet not one program in the whole build worked. I detected this problem before the resulting build was actually shipped over to QA - otherwise management might have killed someone.
[toc] | [prev] | [next] | [standalone]
| From | Pasquale Frega <zemir_fp@libero.it> |
|---|---|
| Date | 2011-11-04 11:57 -0700 |
| Message-ID | <9bb535c2-10b6-4e0c-89cc-af96862e8452@es7g2000vbb.googlegroups.com> |
| In reply to | #12709 |
Hi all, a simple question about "scanf": can i set it in manner to read a simple return with nothing or an escape? If no, what can i use? Thanks!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-11-04 14:44 -0700 |
| Message-ID | <lnhb2jftpx.fsf@nuthaus.mib.org> |
| In reply to | #12710 |
Pasquale Frega <zemir_fp@libero.it> writes:
> Hi all, a simple question about "scanf":
> can i set it in manner to read a simple return with nothing or an
> escape?
> If no, what can i use?
> Thanks!
If you have a question, please post it as a new article, not as a
followup in an unrelated thread.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | "osmium" <r124c4u102@comcast.net> |
|---|---|
| Date | 2011-11-04 14:03 -0500 |
| Message-ID | <9hir8hF9i2U1@mid.individual.net> |
| In reply to | #12709 |
"Gordon Burditt" <gordonb.e1fpi@burditt.org> wrote in message news:2aednaX5Rs5srinTnZ2dnUVZ_rmdnZ2d@posted.internetamerica... >>> Q: "explain how an OS uses the return value from main()" >>> A: "a value of 0 indicates success and EXIT_FAILURE indicates failure" > *For further details, consult the documentation of the program you > are running.* > > In a very real sense, the OS doesn't *use* the return value from > main() much (although it might log it). It provides the information > to applications, so *applications* can use it. The applications > generally know what they are invoking, and can use program-specific > knowledge of what the program they are invoking does (and they need > similar knowledge to correctly invoke the program in the first > place). I am taking a somewhat narrower view of "OS" and a wider > view of "applications" than some may be used to. The kernel, command > interpreters, and such are included, but program development software > like compilers isn't, even if it comes with the OS distribution. > > For many programs the binary SUCCESS/FAILURE return is useful. One > that uses it extensively is "make": it stops a program build if a > step fails. There is a syntax to avoid the abort, if desired, for > specific commands. Compilers, assemblers, linkers, etc. return an > appropriate values. GCC's -Werror option lets you decide to stop > builds on warnings if compiling from "make". If a program *aborts*, > say by calling abort(), segmentation violation, manually being > killed, or being interrupted with a character typed from the keyboard > (e.g. ^C), etc., it is given an exit status which is treated as a > failure, so it may still be useful to test the status even if the > program never does exit(EXIT_FAILURE). Shells use this so they > (not the program that crashed) can print "Segmentation violation" > when it happens. > > There are also a bunch of little UNIX shell commands like test, > expr, etc. whose primary function is to test something and set the > return code accordingly, so shell scripts can do conditional testing. > This is one thing that makes shell scripts powerful. Shells make > the return code available to shell scripts, which can use it to > take action to notify of failures or recover from them. > > Program termination codes go back at least as far as OS/360 JCL, > where "error" status from a compiler indicated that you shouldn't > bother trying to link the resulting object code (if any was produced). > > It's unfortunate that UNIX really only had one standard "success" > value. For example, there are a number of "file compare" programs > (cmp, diff, rcsdiff, etc.) which are usable from shell scripts and > other programs that want to give one of 3 possible results: > files compare equal (0) > files compare unequal (1) > comparison failed (e.g. file does not exist, permission denied, > i/o error, etc.) (2) > where the first two are really two different kinds of "success", > but you can't indicate that, so "files unequal" is treated as a > different subtype of failure. File search programs like "grep" and > family also use this return code pattern (match found / no match > found / problems scanning file). I have sometimes wished for two > different symbols: > EXIT_SUCCESS_WITH_PROMOTION_AND_RAISE > and > EXIT_SUCCESS_YOU_GET_TO_KEEP_YOUR_JOB_ANOTHER_WEEK > which denote two different levels of "success". > > Many programs will report obvious failures to do what was requested > with EXIT_FAILURE if the OS returns errors like I/O error, permission > error, file does not exist, out of memory, out of disk space, etc., > and it wasn't able to work around it. Testing the return status > of a "file copy" program should provide an indication of whether > it worked or not, to the extent that the OS reports problems back > to the program. > > Programs that need more complex status returned to their invoker > can go beyond the C standard and use the POSIX guarantee of being > able to return 0 - 255. (Other programs have been known to use > standard output or standard error, which the invoker redirects and > parses). Return codes are not a substitute for error messages > giving specific detail (like the name of the file the operation > failed on, what operation was attempted, and what error you got). > > There is a whole include file, <sysexits.h> (not specified by any > standard as far as I know, and used extensively by Sendmail), full > of exit return codes for *MAIL TRANSPORT PROGRAMS*. Mail transport > programs try to deliver mail using various methods and use specific > exit codes (forms of failure) beyond those specified by the C > standard, and programs that call them can either treat any value > not equal to 0 or EXIT_SUCCESS as a failure, or they can use specific > knowledge of the failure type to determine remedial action (for > example, retrying the exact same request again later is highly > appropriate for some error classes and pointless for others). The > return codes in <sysexits.h> might be stretched to deal with some > other network-oriented program but they are not useful for programs > in general. > Some examples: > EX_NOHOST - the host specified did not exist. > EX_NOUSER - the user specified did not exist. > EX_USAGE - the command was used incorrectly, e.g. with the wrong > number of arguments, a bad flag, or bad syntax. > EX_TEMPFAIL - a temporary failure, such as not being able to create > a network connection, and the request should be retried. > EX_OSFILE - some system file does not exist, cannot be opened, or > has some sort of error. > EX_IOERR - An error occurred while doing I/O on some file. > > >> Soooooo...is that it? Anything else to add? Anything to say >> about a much more complex program where this binary return value >> and use in a script wouldn't be of much use or sense? > > It's impossible to come up with a useful set of universal exit > codes. Programs have too much variety. A program "identifylanguage" > given a text file might use exit(54) to mean "Vietnamese". Also, > any blatantly obvious success condition (like "file *DOES* exist") > can be a fatal error. Beyond the class of "success" or "failure", > code meanings will be individual by program (or perhaps group of similar > programs) if you want to use under 128 bits for an exit code. > > A hopelessly interactive program (such as an editor) should report > errors to the user via stderr (or a window pop-up, or whatever) > instead of exiting, although having an editor being fed a script > report blatant problems like not being able to open or save files > or running out of memory or disk space via return code (in addition > to an error message) is useful. > > A co-worker once decided (well before C89) that a program that > dropped off the end of main() should return 0, rather than random > status. Unfortunately, the unauthorized and untested change he > made also had the effect that "return N;" in main() also returned > 0. The change he made affected the cross-compiler, meaning it would > return successful status for anything it tried to compile whether > it worked or not. Someone introduced a typo into a critical part > of the C library for the target system. The result: an overnight > build which *apparently* succeeded, (as opposed to a build which > should have died in half an hour) yet not one program in the whole > build worked. I detected this problem before the resulting build > was actually shipped over to QA - otherwise management might have > killed someone. > >
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2011-11-04 21:37 +0000 |
| Message-ID | <20111104173643.378@kylheku.com> |
| In reply to | #12709 |
On 2011-11-04, Gordon Burditt <gordonb.e1fpi@burditt.org> wrote: >>> Q: "explain how an OS uses the return value from main()" >>> A: "a value of 0 indicates success and EXIT_FAILURE indicates failure" > *For further details, consult the documentation of the program you > are running.* > > In a very real sense, the OS doesn't *use* the return value from That's true, but in the C language there is a sense of "use" which means simply to look at a value (even to just propagate it elsewhere). An adequate answer to the question is that the OS (or whatever it is that calls your program) uses the return value in order to establish a termination status (which is something related to that value, but is not that value). Other programs then use the termination status.
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <thefatphil_demunged@yahoo.co.uk> |
|---|---|
| Date | 2011-11-06 12:20 +0200 |
| Message-ID | <87mxc9h7rh.fsf@bazspaz.fatphil.org> |
| In reply to | #12724 |
Kaz Kylheku <kaz@kylheku.com> writes: > On 2011-11-04, Gordon Burditt <gordonb.e1fpi@burditt.org> wrote: > >>> Q: "explain how an OS uses the return value from main()" > >>> A: "a value of 0 indicates success and EXIT_FAILURE indicates failure" > > *For further details, consult the documentation of the program you > > are running.* > > > > In a very real sense, the OS doesn't *use* the return value from > > That's true, except when it's false. Userspace helpers, anyone? > but in the C language there is a sense of "use" which > means simply to look at a value (even to just propagate it elsewhere). > > An adequate answer to the question is that the OS (or whatever it is that calls > your program) uses the return value in order to establish a termination status > (which is something related to that value, but is not that value). > > Other programs then use the termination status. If you're ignoring userspace helpers, then that indeed is better description of what happens. Phil -- Unix is simple. It just takes a genius to understand its simplicity -- Dennis Ritchie (1941-2011), Unix Co-Creator
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-11-04 08:32 -0700 |
| Message-ID | <d060698d-b224-4c2b-b39a-3cbc00146f29@r2g2000vbj.googlegroups.com> |
| In reply to | #12636 |
On Nov 4, 12:32 am, Bill Reid <hormelf...@gmail.com> wrote:
> you
> know, the thing about WHY you would set either "EXIT_SUCCESS"
> or "EXIT_FAILURE" from main(); maybe the other "computer
> expert" can answer that one better...
>
/*
Here's a program which enhances a medical X-ray image, essential so
a human expert can analyse the image to see if a disease is present.
*/
int main(int argc, char **argv)
{
unsigned char *image;
int width, height;
int err;
if(argc != 3)
{
/* we were called with the incorrect number of arguments. Tell
user how to use program */
printf("Usage: enhanceimage <xrayimage.jpeg> <enahncedoutput.jpeg>
\n");
return EXIT_FAILURE;
}
image = loadjpeg(argv[1], &width, &height);
if(!image)
return EXIT_FAILURE;
err = enhanceimage(image, width, height);
if(err != 0)
return EXIT_FAILURE; /* for some reason algorithm to enhance image
fell over */
err = savejpeg(argv[2], image, width, height);
if(err != 0)
return EXIT_FAILURE;
free(image);
/* image loaded, enhanced and saved correctly */
return 0;
}
Now some medical programming person is using a high-level language,
maybe Perl, to dish up the enhanced images to a webserver.
He writes
$enhancedimagename = "temp.jpeg"; # put the enhanced image in a
temporary buffer
$err = system($rawimagename, $enhancedimagename);
if($err == 0)
diplayimage(enhancedimagename);
else
# do something here to indicate that the image held in temp.jpeg is
NOT an enhanced image for the correct patient.
This might not be the best-designed system in the world. But it is
correct. The return provides an easy way to tell the calling script
whether the image was correctly enhanced or not.
--
For implementations of savejpeg() and loadjpeg() read Basic Algorithms
http://www.malcolmmclean.site11.com/www
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web