Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #12449 > unrolled thread

I am learning C: a little problem with a simple source code

Started byzemir <zemir_fp@libero.it>
First post2011-11-01 08:27 -0700
Last post2011-11-02 06:11 -0700
Articles 20 on this page of 146 — 41 participants

Back to article view | Back to comp.lang.c


Contents

  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 →


#12585

FromMalcolm McLean <malcolm.mclean5@btinternet.com>
Date2011-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]


#12636

FromBill Reid <hormelfree@gmail.com>
Date2011-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]


#12664

FromNick Keighley <nick_keighley_nospam@hotmail.com>
Date2011-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]


#12676

FromBill Reid <hormelfree@gmail.com>
Date2011-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]


#12689

FromJohn Gordon <gordon@panix.com>
Date2011-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]


#12693

FromBill Reid <hormelfree@gmail.com>
Date2011-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]


#12698

FromJohn Gordon <gordon@panix.com>
Date2011-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]


#12712

FromBill Reid <hormelfree@gmail.com>
Date2011-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]


#12717

FromJohn Gordon <gordon@panix.com>
Date2011-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]


#12768

FromMalcolm McLean <malcolm.mclean5@btinternet.com>
Date2011-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]


#12700

FromJohn Gordon <gordon@panix.com>
Date2011-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]


#12711

FromBill Reid <hormelfree@gmail.com>
Date2011-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]


#12702

From"io_x" <a@b.c.invalid>
Date2011-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]


#12709

Fromgordonb.e1fpi@burditt.org (Gordon Burditt)
Date2011-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]


#12710

FromPasquale Frega <zemir_fp@libero.it>
Date2011-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]


#12726

FromKeith Thompson <kst-u@mib.org>
Date2011-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]


#12714

From"osmium" <r124c4u102@comcast.net>
Date2011-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]


#12724

FromKaz Kylheku <kaz@kylheku.com>
Date2011-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]


#12810

FromPhil Carmody <thefatphil_demunged@yahoo.co.uk>
Date2011-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]


#12684

FromMalcolm McLean <malcolm.mclean5@btinternet.com>
Date2011-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