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 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | Bill Reid <hormelfree@gmail.com> |
|---|---|
| Date | 2011-11-04 09:04 -0700 |
| Message-ID | <ad909155-95d3-4d43-b719-fb82f653b345@g21g2000yqc.googlegroups.com> |
| In reply to | #12684 |
On Nov 4, 8:32 am, Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> 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.
> */
>
Wrong, this is a program that contains numerous basic
programming errors...
> int main(int argc, char **argv)
> {
Gee, did you forget some stuff?
> 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");
What's "printf()"? Where did you prototype it?
> return EXIT_FAILURE;
> }
> image = loadjpeg(argv[1], &width, &height);
What's "loadjpeg()"? Where did you prototype it?
> if(!image)
> return EXIT_FAILURE;
> err = enhanceimage(image, width, height);
What's "enhanceimage()"? Where did you prototype it?
> if(err != 0)
> return EXIT_FAILURE; /* for some reason algorithm to enhance image
> fell over */
> err = savejpeg(argv[2], image, width, height);
What's "savejpeg()"? Where did you prototype it?
> if(err != 0)
> return EXIT_FAILURE;
>
> free(image);
Just what do you think you're free'ing here?
> /* 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.
>
Did you even bother to link the relevant libraries?
Now some medical programming person is cursing your
complete incompetence...
> 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.
>
Patient DEAD, and not just because of all YOUR
egregious programming errors...also, couldn't he
have just used "enhanceimage()" in the script if
you had merely compiled THAT as a complete program?
> This might not be the best-designed system in the world.
You think? Sheesh...you're the Conrad Murray of medical
programmers...
> But it is
> correct.
For very small or inverse values of "correct"...
> The return provides an easy way to tell the calling script
> whether the image was correctly enhanced or not.
>
This is why I don't like to go to the doctor; the same
kinds of goofballs who can't write a simple Internet
browser that works properly hold my life in their hands...
>
> For implementations of savejpeg() and loadjpeg() read Basic Algorithmshttp://www.malcolmmclean.site11.com/www
>
Got anything for mpegs? Including the Dolby Digital(TM)
soundtracks? Oh, and something that actually works...
---
William Ernest Reid
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-11-04 10:28 -0700 |
| Message-ID | <3ee23394-914a-4838-a0cb-c03f919cf01b@t8g2000yql.googlegroups.com> |
| In reply to | #12695 |
On Nov 4, 6:04 pm, Bill Reid <hormelf...@gmail.com> wrote: > > What's "printf()"? Where did you prototype it? > I forgot. Fortunately modern compilers will pick up that error, and issue a warning. So no one will die as a result. > > Did you even bother to link the relevant libraries? > Now some medical programming person is cursing your > complete incompetence... > If the program doesn't link, no executable will be generated at all. We might have to mess about with linking, but no-one will die as a result of setting up the linker incorrectly. > > Patient DEAD, and not just because of all YOUR > egregious programming errors...also, couldn't he > have just used "enhanceimage()" in the script if > you had merely compiled THAT as a complete program? > The patient can't die because of my personal incompetence. That's the beauty of doing things the recommended way. The system catches your mistakes. If you never make a mistake, you can write raw machine code and the program will always execute correctly. Programming languages are only needed at all because some people do make mistakes. Now why can't the Perl programmer just call "enhanceimage" directly? The reason is that the trivial is important. At some point, the program is going to have to deal with the rgb colour values that make up the image. It's going to have to know what format these values are in, whether they are 24 bit rgb, 32 bit bgra, 3 channle floats, or whatever. What the program does is provide an interface between a standard image file format, in this case jpeg (not a good choice for medical images, but it allows me to plug the jpeg codec in Basic Algorithms), and enhanceimage. If this isn't done, the Perl programmer will have to set up an array of bytes. Perl's not the right language for that sort of thing. it is the right language for manipulating file names and tieing a jpeg image to an html page describing the patient's symptoms, the results of his other tests, and so on. > > > This might not be the best-designed system in the world. > > You think? Sheesh...you're the Conrad Murray of medical > programmers... > > > But it is > > correct. > > For very small or inverse values of "correct"... > > > The return provides an easy way to tell the calling script > > whether the image was correctly enhanced or not. > > This is why I don't like to go to the doctor; the same > kinds of goofballs who can't write a simple Internet > browser that works properly hold my life in their hands... > > The trivial is important. If you set up an expectation that programs which fail return an error condition, then calling programmers may rely on this condition, without checking the program documentation. Obviously there should be processes to prevent that from happening, but the point is that you've slipped past the normal safety controls, and are relying on the last ditch defence. That might fail, because the program is behind schedule, it passed its last quality control check, only a couple of lines of trivial code to enhance the image have been added. The quality control person decides not to throw the full q a test suite at it because that means it will be delivered late and trigger penalty clauses. Inexcusable, but these things can happen. So the program is run, and works successfully for many years. Then, one day, the computer runs out of memory and loadjpeg() fails. The image in test.jpeg is not updated. No error return is given to the calling Perl program, and the webpage is generated, with an image from the previous patient. The previous patient was healthy, this one has the dreaded creeping crud, which can be cured if treated in time, but is deadly if there is even a few hours delay in administering the medicinal compound. And that's how void main() can kill somebody.
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-11-03 18:35 +0000 |
| Message-ID | <slrnjb5nok.2nnt.usenet-nospam@guild.seebs.net> |
| In reply to | #12583 |
On 2011-11-03, Bill Reid <hormelfree@gmail.com> wrote:
> Oh great, somebody who knows how computers work, I've been looking
> for somebody like that to explain something...
:)
> 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?
All of the ones I'm aware of use it as an indicator of the success or
failure status of a process. While the Windows GUI mostly ignores
those (mostly), in the DOS or Unix shells, either way, if you use a
command as a conditional, the return status of main() is what determines
whether it's "true" or "false".
> And while you're on the subject, how should a computer
> expert such as yourself set the return value of main() to be
> correct?
EXIT_SUCCESS or EXIT_FAILURE.
> Can you define what conditions would cause me to set it one
> way or another? Of course, I'm assuming that since the
> ANSI C committee decreed that main() have a specific set
> of return values, every computer in the world conforms
> to those values and does something useful with them, so
> I would have perfect "portability" between platforms
> for my "correct" C code, and nobody would die as a result
> of my using an incorrect return value...
Not everything does something useful with them, but most of the major
systems you'll encounter do, in fact, do something useful with them.
And while I'm sure you think you're being hilariously witty and sarcastic
about people dying... Attitudes like yours are why computers DO kill
people sometimes, because someone assumes that something that worked once
in a test will be fine, and then in the real world, the random hunk
of memory that ended up determining whether to take path A or path B through
some other code ends up having a bit set, and Whoops.
If you want to see the roots of how this works, grab yourself a Unix
prompt (cygwin will do), and try:
int main(void) {
return 3;
}
compile this, run it, and then "echo $?", and you should get "3". Probably.
(In a Unix-like environment, it's actually guaranteed. It's not necessarily
portable more broadly.)
The values which have formal definitions are:
0, EXIT_SUCCESS: Indicate success
EXIT_FAILURE: Indicate failure
Interestingly, this is true even on platforms (such as VMS) where a program
exit status of 0 is failure; the runtime is required to correctly translate
those three values to the environment's standards.
> Also, what's "winmain()"? I've seen that a lot, returns
> something called a "Windows handle", what's up with that?
That would be traditional Windows being what is called a "freestanding
environment", which is to say, one which doesn't conform to the C standard's
rules for a "hosted" environment. Normally, a "freestanding environment"
is used for something like a tiny embedded board with little to no operating
system. One of the interesting side effects was that some Windows compilers
chose not to offer a working <stdio.h> or the related functionality when
they were used in the mode where they started execution at winmain().
(I believe I've seen claims that at least one omitted *sprintf* too in
this mode. Which is allowed, and goes to show why you always want a
hosted implementation if possible.)
> You know, I've asked these questions here before, but
> never received an answer, but I'm sure that's because
> there wasn't a computer expert such as yourself to answer
> them...
I'd guess it's most likely because they're only sort of topical. Either
that or because your hostile and sarcastic tone made people assume you
weren't serious. (Me, I don't care; you may not be planning to read the
response, but someone else might.)
-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | Pasquale Frega <zemir_fp@libero.it> |
|---|---|
| Date | 2011-11-03 14:50 -0700 |
| Message-ID | <f1461d2b-dc95-4896-9137-66f0aa5d6567@l19g2000yqc.googlegroups.com> |
| In reply to | #12612 |
Hi all, very thanks for your suggestions, you are a treasure for me;
however i have a new version of my code:
#include <stdio.h>;
#include <math.h>;
const long double Pi = 3.14159265358979323846;
float area(float r) { /*define area
function*/
return(r*r*Pi);
}
float perimeter(float r) { /*define perimeter
function*/
return(2*Pi*r);
}
int main(void) {
system("cls");
float r=0; char c; int i;
/*define radius and c variable used to control the behaviour
of program; 'i' needs to clean input buffer*/
printf("This programm calculate Area and Perimenter of a Circle");
do {
printf("\n\nPlease insert radius value (in cm): ");
fflush(stdout);
scanf("%f", &r); /*input of the radius value*/
if(r>0) {
printf("\nArea is cm2: %.2f \n\nPerimeter is cm: %.2f\n", area(r),
perimeter(r)); /*call area perimeter and
function*/
} else printf("\nValue must to be a valid number\n");
while(i=getchar()!='\n');
/*clean input buffer*/
r=0;
/*reset radius value*/
printf("\nPress any key to continue ESC to exit");
c=getch();
} while(c!='\e');
}
Now it works fine; i follow a simple rule: write as fewer as possible.
Is it right (comments apart)?..........About main, on my compiler
there is not different about the various versions, official and
no............... i like "void main()", but such as a lot of you say
and such as i understand, i will use "int main(void)".............for
the rest, i think, the importat is that the program must to do exactly
as i want, the rest is irrelevant.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-11-03 15:59 -0700 |
| Message-ID | <ln39e4hkwy.fsf@nuthaus.mib.org> |
| In reply to | #12629 |
Pasquale Frega <zemir_fp@libero.it> writes:
> Hi all, very thanks for your suggestions, you are a treasure for me;
> however i have a new version of my code:
>
>
> #include <stdio.h>;
> #include <math.h>;
> const long double Pi = 3.14159265358979323846;
> float area(float r) { /*define area
> function*/
> return(r*r*Pi);
> }
> float perimeter(float r) { /*define perimeter
> function*/
> return(2*Pi*r);
> }
> int main(void) {
> system("cls");
> float r=0; char c; int i;
> /*define radius and c variable used to control the behaviour
> of program; 'i' needs to clean input buffer*/
> printf("This programm calculate Area and Perimenter of a Circle");
> do {
> printf("\n\nPlease insert radius value (in cm): ");
> fflush(stdout);
> scanf("%f", &r); /*input of the radius value*/
> if(r>0) {
> printf("\nArea is cm2: %.2f \n\nPerimeter is cm: %.2f\n", area(r),
> perimeter(r)); /*call area perimeter and
> function*/
> } else printf("\nValue must to be a valid number\n");
> while(i=getchar()!='\n');
> /*clean input buffer*/
> r=0;
> /*reset radius value*/
> printf("\nPress any key to continue ESC to exit");
> c=getch();
> } while(c!='\e');
> }
Your code layout makes my eyes bleed, especially with long lines being
folded (probably by some news software somewhere).
Here's a reformatted version of your program, with some bugs correct.
It's still not perfect (I find that I have to type control-D twice to
exit). Study the changes I've made and the comments I've added. Note
in particular that I've dropped the call to getch(), which is
non-standard.
#include <stdio.h>
#include <math.h>
const long double Pi = 3.14159265358979323846;
float area(float r) {
return r*r*Pi;
}
float perimeter(float r) {
return 2*Pi*r;
}
int main(void) {
/* system("cls"); */
/*
* Why do you want to clear my screen when I run your program?
* And what if I run it on a system that doesn't have a "cls"
* command -- or, worse, that has a "cls" command that does
* something else? If I want to erase my screen, possibly
* destroying information that has nothing to do with your
* program, I can do it myself, thankyouverymuch.
*/
float r=0;
int c;
int items_read;
/* define radius and c variable used to control the behaviour
of program; 'i' needs to clean input buffer*/
printf("This programm calculate Area and Perimenter of a Circle");
do {
printf("\n\nPlease insert radius value (in cm): ");
fflush(stdout);
items_read = scanf("%f", &r); /*input of the radius value*/
if (items_read == 1 && r > 0.0) {
printf("\nArea is cm2: %.2f \n\nPerimeter is cm: %.2f\n",
area(r),
perimeter(r));
}
else {
printf("\nValue must to be a valid number\n");
}
while ((c=getchar()) != '\n' && c != EOF)
;
} while (c != EOF);
return 0;
}
--
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 | Pasquale Frega <zemir_fp@libero.it> |
|---|---|
| Date | 2011-11-04 12:00 -0700 |
| Message-ID | <bd8d8f57-a7b2-44ef-8edf-4fdda7a7db4d@p1g2000yqh.googlegroups.com> |
| In reply to | #12639 |
On Nov 3, 11:59 pm, Keith Thompson <ks...@mib.org> wrote:
> Pasquale Frega <zemir...@libero.it> writes:
> > Hi all, very thanks for your suggestions, you are a treasure for me;
> > however i have a new version of my code:
>
> > #include <stdio.h>;
> > #include <math.h>;
> > const long double Pi = 3.14159265358979323846;
> > float area(float r) { /*define area
> > function*/
> > return(r*r*Pi);
> > }
> > float perimeter(float r) { /*define perimeter
> > function*/
> > return(2*Pi*r);
> > }
> > int main(void) {
> > system("cls");
> > float r=0; char c; int i;
> > /*define radius and c variable used to control the behaviour
> > of program; 'i' needs to clean input buffer*/
> > printf("This programm calculate Area and Perimenter of a Circle");
> > do {
> > printf("\n\nPlease insert radius value (in cm): ");
> > fflush(stdout);
> > scanf("%f", &r); /*input of the radius value*/
> > if(r>0) {
> > printf("\nArea is cm2: %.2f \n\nPerimeter is cm: %.2f\n", area(r),
> > perimeter(r)); /*call area perimeter and
> > function*/
> > } else printf("\nValue must to be a valid number\n");
> > while(i=getchar()!='\n');
> > /*clean input buffer*/
> > r=0;
> > /*reset radius value*/
> > printf("\nPress any key to continue ESC to exit");
> > c=getch();
> > } while(c!='\e');
> > }
>
> Your code layout makes my eyes bleed, especially with long lines being
> folded (probably by some news software somewhere).
>
> Here's a reformatted version of your program, with some bugs correct.
> It's still not perfect (I find that I have to type control-D twice to
> exit). Study the changes I've made and the comments I've added. Note
> in particular that I've dropped the call to getch(), which is
> non-standard.
>
> #include <stdio.h>
> #include <math.h>
>
> const long double Pi = 3.14159265358979323846;
>
> float area(float r) {
> return r*r*Pi;
>
> }
>
> float perimeter(float r) {
> return 2*Pi*r;
>
> }
>
> int main(void) {
> /* system("cls"); */
> /*
> * Why do you want to clear my screen when I run your program?
> * And what if I run it on a system that doesn't have a "cls"
> * command -- or, worse, that has a "cls" command that does
> * something else? If I want to erase my screen, possibly
> * destroying information that has nothing to do with your
> * program, I can do it myself, thankyouverymuch.
> */
>
> float r=0;
> int c;
> int items_read;
> /* define radius and c variable used to control the behaviour
> of program; 'i' needs to clean input buffer*/
>
> printf("This programm calculate Area and Perimenter of a Circle");
> do {
> printf("\n\nPlease insert radius value (in cm): ");
> fflush(stdout);
> items_read = scanf("%f", &r); /*input of the radius value*/
> if (items_read == 1 && r > 0.0) {
> printf("\nArea is cm2: %.2f \n\nPerimeter is cm: %.2f\n",
> area(r),
> perimeter(r));
> }
> else {
> printf("\nValue must to be a valid number\n");
> }
>
> while ((c=getchar()) != '\n' && c != EOF)
> ;
> } while (c != EOF);
> return 0;
>
> }
>
> --
> Keith Thompson (The_Other_Keith) ks...@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"
Hi Keith, i have compiled your version, it works but no exactly as i
want; i intend a bit different working. However, thanks!
[toc] | [prev] | [next] | [standalone]
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2011-11-04 20:58 +0100 |
| Message-ID | <4eb4430c$0$1381$4fafbaef@reader1.news.tin.it> |
| In reply to | #12639 |
"Keith Thompson" <kst-u@mib.org> ha scritto nel messaggio
news:ln39e4hkwy.fsf@nuthaus.mib.org...
> Your code layout makes my eyes bleed, especially with long lines being
> folded (probably by some news software somewhere).
>
> Here's a reformatted version of your program, with some bugs correct.
> It's still not perfect (I find that I have to type control-D twice to
> exit).
i can exit only using ctrl-c
i try ctrl-d and ctr-z but not a success for exit the loop...
what is ctrl key for rapresent EOF for windows?
> Study the changes I've made and the comments I've added. Note
> in particular that I've dropped the call to getch(), which is
> non-standard.
>
> #include <stdio.h>
> #include <math.h>
>
> const long double Pi = 3.14159265358979323846;
>
> float area(float r) {
> return r*r*Pi;
> }
>
> float perimeter(float r) {
> return 2*Pi*r;
> }
>
> int main(void) {
> /* system("cls"); */
> /*
> * Why do you want to clear my screen when I run your program?
> * And what if I run it on a system that doesn't have a "cls"
> * command -- or, worse, that has a "cls" command that does
> * something else? If I want to erase my screen, possibly
> * destroying information that has nothing to do with your
> * program, I can do it myself, thankyouverymuch.
> */
>
> float r=0;
> int c;
> int items_read;
> /* define radius and c variable used to control the behaviour
> of program; 'i' needs to clean input buffer*/
>
> printf("This programm calculate Area and Perimenter of a Circle");
> do {
> printf("\n\nPlease insert radius value (in cm): ");
> fflush(stdout);
> items_read = scanf("%f", &r); /*input of the radius value*/
if(feof(stdin)||ferror(stdin)) return 0;
> if (items_read == 1 && r > 0.0) {
> printf("\nArea is cm2: %.2f \n\nPerimeter is cm: %.2f\n",
> area(r),
> perimeter(r));
> }
> else {
> printf("\nValue must to be a valid number\n");
> }
>
> while ((c=getchar()) != '\n' && c != EOF)
> ;
it seems i not find ctrl key for EOF here in windows...
yes i find it it is number^z; ^z only is not ok
so it can depend on scanf input way; so i add the line
"if(feof(stdin)||ferror(stdin)) return 0;"
above; i don't know if it is right...
> } while (c != EOF);
> return 0;
> }
>
> --
> 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 | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2011-11-04 21:13 +0100 |
| Message-ID | <4eb4469b$0$1386$4fafbaef@reader2.news.tin.it> |
| In reply to | #12719 |
"io_x" <a@b.c.invalid> ha scritto nel messaggio
news:4eb4430c$0$1381$4fafbaef@reader1.news.tin.it...
>
> "Keith Thompson" <kst-u@mib.org> ha scritto nel messaggio
> news:ln39e4hkwy.fsf@nuthaus.mib.org...
>> Your code layout makes my eyes bleed, especially with long lines being
>> folded (probably by some news software somewhere).
>>
>> Here's a reformatted version of your program, with some bugs correct.
>> It's still not perfect (I find that I have to type control-D twice to
>> exit).
>
> i can exit only using ctrl-c
> i try ctrl-d and ctr-z but not a success for exit the loop...
> what is ctrl key for rapresent EOF for windows?
>
>> Study the changes I've made and the comments I've added. Note
>> in particular that I've dropped the call to getch(), which is
>> non-standard.
>>
>> #include <stdio.h>
>> #include <math.h>
>>
>> const long double Pi = 3.14159265358979323846;
>>
>> float area(float r) {
>> return r*r*Pi;
>> }
>>
>> float perimeter(float r) {
>> return 2*Pi*r;
>> }
>>
>> int main(void) {
>> /* system("cls"); */
>> /*
>> * Why do you want to clear my screen when I run your program?
>> * And what if I run it on a system that doesn't have a "cls"
>> * command -- or, worse, that has a "cls" command that does
>> * something else? If I want to erase my screen, possibly
>> * destroying information that has nothing to do with your
>> * program, I can do it myself, thankyouverymuch.
>> */
>>
>> float r=0;
>> int c;
>> int items_read;
>> /* define radius and c variable used to control the behaviour
>> of program; 'i' needs to clean input buffer*/
>>
>> printf("This programm calculate Area and Perimenter of a Circle");
>> do {
>> printf("\n\nPlease insert radius value (in cm): ");
>> fflush(stdout);
>> items_read = scanf("%f", &r); /*input of the radius value*/
>
> if(feof(stdin)||ferror(stdin)) return 0;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
this above is wrong
>> if (items_read == 1 && r > 0.0) {
>> printf("\nArea is cm2: %.2f \n\nPerimeter is cm: %.2f\n",
>> area(r),
>> perimeter(r));
>> }
>> else {
>> printf("\nValue must to be a valid number\n");
>> }
if(feof(stdin)||ferror(stdin)) return 0;
this just above is better
>> while ((c=getchar()) != '\n' && c != EOF)
>> ;
>
> it seems i not find ctrl key for EOF here in windows...
> yes i find it it is number^z; ^z only is not ok
> so it can depend on scanf input way; so i add the line
> "if(feof(stdin)||ferror(stdin)) return 0;"
> above; i don't know if it is right...
>
>> } while (c != EOF);
>> return 0;
>> }
>>
>> --
>> 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 | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-11-04 01:56 -0700 |
| Message-ID | <ffcdd114-5b66-4152-9746-d14757fe1862@gy7g2000vbb.googlegroups.com> |
| In reply to | #12629 |
On Nov 3, 9:50 pm, Pasquale Frega <zemir...@libero.it> wrote:
> Hi all, very thanks for your suggestions, you are a treasure for me;
> however i have a new version of my code:
<snip>
your code is still rather poorly laid out.
> Now it works fine;
good!
> i follow a simple rule: write as fewer as possible.
"write as little as possible" or "write as few lines as possible"?
Sounds like a variant on
"everything should be made as simple as possible, but no simpler"
Some Scientist
I'd say strive for clarity. So don't pack your code really tightly if
it obscures your purpose. Write simple straightforward code. Only
deviate from this if you need (*really* need) the performance or some
other constraint pushes you away from perfect clarity.
> Is it right (comments apart)?..........About main, on my compiler
> there is not different about the various versions, official and
> no............... i like "void main()",
I wish I was decended from bears but my wishes don't change the facts.
> but such as a lot of you say
> and such as i understand, i will use "int main(void)".............for
> the rest, i think, the importat is that the program must to do exactly
> as i want, the rest is irrelevant.
layout, clarity etc. if your progarm is going to have any sort of
extended lifetime. Unlikely in this case but it's sensible to start
with good habbits.
[toc] | [prev] | [next] | [standalone]
| From | Pasquale Frega <zemir_fp@libero.it> |
|---|---|
| Date | 2011-11-04 12:12 -0700 |
| Message-ID | <f72b4d2f-f75f-4981-8662-bed8158b0c8f@es7g2000vbb.googlegroups.com> |
| In reply to | #12666 |
On Nov 4, 9:56 am, Nick Keighley <nick_keighley_nos...@hotmail.com> wrote: > On Nov 3, 9:50 pm, Pasquale Frega <zemir...@libero.it> wrote: > > > Hi all, very thanks for your suggestions, you are a treasure for me; > > however i have a new version of my code: > > <snip> > > your code is still rather poorly laid out. > > > Now it works fine; > > good! > > > i follow a simple rule: write as fewer as possible. > > "write as little as possible" or "write as few lines as possible"? > > Sounds like a variant on > "everything should be made as simple as possible, but no simpler" > Some Scientist > > I'd say strive for clarity. So don't pack your code really tightly if > it obscures your purpose. Write simple straightforward code. Only > deviate from this if you need (*really* need) the performance or some > other constraint pushes you away from perfect clarity. > > > Is it right (comments apart)?..........About main, on my compiler > > there is not different about the various versions, official and > > no............... i like "void main()", > > I wish I was decended from bears but my wishes don't change the facts. > > > but such as a lot of you say > > and such as i understand, i will use "int main(void)".............for > > the rest, i think, the importat is that the program must to do exactly > > as i want, the rest is irrelevant. > > layout, clarity etc. if your progarm is going to have any sort of > extended lifetime. Unlikely in this case but it's sensible to start > with good habbits. My stile is my stile, i will try to improve it but it is going to take its way. I always will comment my code, if in the future you should read some my program, it is sure you find all needs to understand and to change it! As short, as clear, as well as possible.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-11-05 10:09 +1300 |
| Message-ID | <9hj2joF62fU2@mid.individual.net> |
| In reply to | #12715 |
On 11/ 5/11 08:12 AM, Pasquale Frega wrote: > On Nov 4, 9:56 am, Nick Keighley<nick_keighley_nos...@hotmail.com> > wrote: >> >> layout, clarity etc. if your progarm is going to have any sort of >> extended lifetime. Unlikely in this case but it's sensible to start >> with good habbits. > My stile is my stile, i will try to improve it but it is going to take > its way. > I always will comment my code, if in the future you should read some > my program, it is sure you find all needs to understand and to change > it! > As short, as clear, as well as possible. Your style includes a lot of pointless comments, which distract the reader and would be a pain for a maintenance programmer. Some examples: /*input of the radius value*/ /*call area perimeter and function*/ /*reset radius value*/ and worst of all: /*define perimeter function*/ None of your comments expansion why you are doing something. If you strive for brevity and clarity, such comments are a strong indicator that you are failing! -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Bill Reid <hormelfree@gmail.com> |
|---|---|
| Date | 2011-11-03 15:32 -0700 |
| Message-ID | <b7fefa1a-8bc0-4364-8104-80aee6c3025c@hj4g2000vbb.googlegroups.com> |
| In reply to | #12612 |
On Nov 3, 11:35 am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2011-11-03, Bill Reid <hormelf...@gmail.com> wrote:
>
> > Oh great, somebody who knows how computers work, I've been looking
> > for somebody like that to explain something...
>
> :)
>
> > 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?
>
> All of the ones I'm aware of use it as an indicator of the success or
> failure status of a process. While the Windows GUI mostly ignores
> those (mostly), in the DOS or Unix shells, either way, if you use a
> command as a conditional, the return status of main() is what determines
> whether it's "true" or "false".
>
Hmmmm, "if you use a command as a conditional", you mean
like a shell script? OK, maybe we're getting a little
closer...maybe...
> > And while you're on the subject, how should a computer
> > expert such as yourself set the return value of main() to be
> > correct?
>
> EXIT_SUCCESS or EXIT_FAILURE.
>
Damn, and you were almost on the right track...your
post returned "EXIT_BEGGING_THE_QUESTION"...
> > Can you define what conditions would cause me to set it one
> > way or another? Of course, I'm assuming that since the
> > ANSI C committee decreed that main() have a specific set
> > of return values, every computer in the world conforms
> > to those values and does something useful with them, so
> > I would have perfect "portability" between platforms
> > for my "correct" C code, and nobody would die as a result
> > of my using an incorrect return value...
>
> Not everything does something useful with them, but most of the major
> systems you'll encounter do, in fact, do something useful with them.
>
OK, maybe I'll answer the question myself, since you're
having some problems doing so...on the "TRUE" Unix(TM) I
worked with for years, there was this circular log that
kept track of all the apps that were launched on the system,
and one of the columns in the table showed the exit status
of the app...simple enough? Sys admins could peruse this
log and maybe glean some type of insight into how the
system was working and being used...
The problem is, the fact that an application developer
chose to return a particular value doesn't really say
a hell of lot about the system function, so I doubt sys
admins really paid much attention to that column.
Now if there were a RULE that EXIT_FAILURE would only
be set for what could be considered system problems during
the running of an app, such as failure to allocate memory,
the log would be a lot more useful...but the "C" standard
is mute on the topic as are the people who claim that
incorrect return values COULD KILL PEOPLE DAMMIT!!!!
> And while I'm sure you think you're being hilariously witty and sarcastic
> about people dying...
No, not that hilarious, just pointing out you were
indulging in some unwarranted fear-mongering...and
you felt free to continue in that vein, even after
being laughed at about it:
> Attitudes like yours are why computers DO kill
> people sometimes, because someone assumes that something that worked once
> in a test will be fine,
Yes, ASSUMPTIONS are the key to what I'm asking
about, DAMMIT!!!
> and then in the real world, the random hunk
> of memory that ended up determining whether to take path A or path B through
> some other code ends up having a bit set, and Whoops.
>
Since you can't specify why the particular
conditional in question would be set, you're
really part of the illogical problem and not
the solution and have PROBABLY KILLED MILLIONS
AS A RESULT!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> If you want to see the roots of how this works, grab yourself a Unix
> prompt (cygwin will do), and try:
>
> int main(void) {
> return 3;
> }
>
> compile this, run it, and then "echo $?", and you should get "3". Probably.
> (In a Unix-like environment, it's actually guaranteed. It's not necessarily
> portable more broadly.)
>
> The values which have formal definitions are:
> 0, EXIT_SUCCESS: Indicate success
> EXIT_FAILURE: Indicate failure
>
> Interestingly, this is true even on platforms (such as VMS) where a program
> exit status of 0 is failure; the runtime is required to correctly translate
> those three values to the environment's standards.
>
Objection, motion to strike, argumentative, unresponsive,
irrelevant...
> > Also, what's "winmain()"? I've seen that a lot, returns
> > something called a "Windows handle", what's up with that?
>
> That would be traditional Windows being what is called a "freestanding
> environment", which is to say, one which doesn't conform to the C standard's
> rules for a "hosted" environment.
Maybe your post should return "EXIT_TAUTOLOGY"; everything
just refers back to the "C" standard, and yet what I asked
about is how the "C" standard can control the behavior of
various operating systems when it can't even specify what
the behavior of an application developer should be in returning
a SPECFIC value to the operating system...
> Normally, a "freestanding environment"
> is used for something like a tiny embedded board with little to no operating
> system. One of the interesting side effects was that some Windows compilers
> chose not to offer a working <stdio.h> or the related functionality when
> they were used in the mode where they started execution at winmain().
> (I believe I've seen claims that at least one omitted *sprintf* too in
> this mode. Which is allowed, and goes to show why you always want a
> hosted implementation if possible.)
>
Your honor, motion to bind and gag the witness!!!
> > You know, I've asked these questions here before, but
> > never received an answer, but I'm sure that's because
> > there wasn't a computer expert such as yourself to answer
> > them...
>
> I'd guess it's most likely because they're only sort of topical.
It's about one of the most frequently answered questions
here (right up there with not casting the return value of
malloc())!!! How can it NOT be topical, IT'S ALWAYS BROUGHT
UP WHETHER ASKED FOR OR NOT!!??!!!
> Either
> that or because your hostile and sarcastic tone made people assume you
> weren't serious.
I'm 100% serious because when I program an effin'
computer I expect "hospital corners" for every effin'
thing I do...if I do something, I want to know EXACTLY
how it will impact the system and my application and
my users (which I TRULY care about, because largely
"my users" is just me, if I did this more "professionally"
I would probably take the more slip-shod attitude toward software
quality displayed frequently here).
> (Me, I don't care; you may not be planning to read the
> response, but someone else might.)
>
I'm reading, so here's a scenario: one application I wrote
automatically downloads hundreds of files a day from all over
the Internet, different web-sites, different formats, etc.
Sometimes, they don't put the file up at the time I
expect it to be there, so the program can't download it.
Other times, due to some sanity checking of various
strings in the files to attempt to determine if they
are the correct files I wanted to download in the first
place (since at times, the webmasters may change what
files they put at a certain link), the file might
not be written to disk until manual perusal to
verify its contents.
Both of those could be considered "failures" of
the application to do what I wanted it to do; so
should I set "EXIT_FAILURE"? (And just to cut to
the chase, I don't, I handle stuff like that, and
Internet connectivity problems, etc., in my own application
"logs", and would only use "EXIT_FAILURE" for something
like a failure to allocate, even though I have no
idea what PRACTICAL benefit that provides me,
since that is separately logged as well.)
---
William Ernest Reid
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-11-03 22:53 +0000 |
| Message-ID | <slrnjb66o4.30j7.usenet-nospam@guild.seebs.net> |
| In reply to | #12635 |
On 2011-11-03, Bill Reid <hormelfree@gmail.com> wrote: > Hmmmm, "if you use a command as a conditional", you mean > like a shell script? OK, maybe we're getting a little > closer...maybe... Yes. > OK, maybe I'll answer the question myself, since you're > having some problems doing so... Er, what? > on the "TRUE" Unix(TM) I > worked with for years, there was this circular log that > kept track of all the apps that were launched on the system, > and one of the columns in the table showed the exit status > of the app...simple enough? Sys admins could peruse this > log and maybe glean some type of insight into how the > system was working and being used... Yup. > The problem is, the fact that an application developer > chose to return a particular value doesn't really say > a hell of lot about the system function, so I doubt sys > admins really paid much attention to that column. They may have paid attention sometimes. > Now if there were a RULE that EXIT_FAILURE would only > be set for what could be considered system problems during > the running of an app, such as failure to allocate memory, > the log would be a lot more useful... That would not be a suitable rule for a language standard. It might be a suitable rule for an operating system standard. It would be a spectacularly stupid rule, though, because there are widespread systems which have very well established rules for such behavior. > but the "C" standard > is mute on the topic As it should be. If you want to do something more specific, you need to do it in a way specific to your environment. > as are the people who claim that > incorrect return values COULD KILL PEOPLE DAMMIT!!!! That's because we're talking about what actually happens in computers, not what would have been an interesting alternative design to consider in a parallel universe where neither Windows nor Unix existed. > No, not that hilarious, just pointing out you were > indulging in some unwarranted fear-mongering... Except that it's not unwarranted. > and > you felt free to continue in that vein, even after > being laughed at about it: That's because the "being laughed at" was stupid and ignorant. > Yes, ASSUMPTIONS are the key to what I'm asking > about, DAMMIT!!! Maybe you should focus less on being a jerk and more on articulating your questions, then? > Objection, motion to strike, argumentative, unresponsive, > irrelevant... So you weren't actually asking the question you asked. > Maybe your post should return "EXIT_TAUTOLOGY"; everything > just refers back to the "C" standard, and yet what I asked > about is how the "C" standard can control the behavior of > various operating systems when it can't even specify what > the behavior of an application developer should be in returning > a SPECFIC value to the operating system... Okay, you seem to be under some kind of strange delusions about the relationship of a language standard to the rest of the world. Operating systems exist, and have requirements that vary based on what they are operating systems for. Language specs don't get to control that. Language specs offer limited standardized functionality, and if you need functionality beyond what they can offer, you have to go look at other specs. If you want the *portable* C answer, the only values that mean anything are 0, EXIT_SUCCESS, and EXIT_FAILURE, and there is no guarantee that every operating system everywhere does anything with them. However, realistically, any implementation that's hosted will at the very least do something vaguely reasonable with these. If you want an answer that's more specific to a platform, then your answer necessarily depends on the specifics of that platform and environment. > It's about one of the most frequently answered questions > here (right up there with not casting the return value of > malloc())!!! The winmain() question isn't. > How can it NOT be topical, IT'S ALWAYS BROUGHT > UP WHETHER ASKED FOR OR NOT!!??!!! It can not be topical because it turns out to be a question about specific operating systems, to which different systems have different answers, not a question about the language. > I'm 100% serious because when I program an effin' > computer I expect "hospital corners" for every effin' > thing I do...if I do something, I want to know EXACTLY > how it will impact the system and my application and > my users Then you'd be well served by learning that a computer system is more than one thing. The language is not the same thing as the operating system, which is not the same thing as the hardware. If you want to know what specific return values do, look at the operating system, because that's what is doing something with them. > I'm reading, so here's a scenario: one application I wrote > automatically downloads hundreds of files a day from all over > the Internet, different web-sites, different formats, etc. That's nice. > Both of those could be considered "failures" of > the application to do what I wanted it to do; so > should I set "EXIT_FAILURE"? That is up to you and your feelings about what your specific operating system does with the values. > (And just to cut to > the chase, I don't, I handle stuff like that, and > Internet connectivity problems, etc., in my own application > "logs", and would only use "EXIT_FAILURE" for something > like a failure to allocate, even though I have no > idea what PRACTICAL benefit that provides me, > since that is separately logged as well.) The main practical benefit is that it offers other programs a way to find out whether your program worked without needing to know that much about your program. Let's say I want to grab a bunch of files. Right now, I'm using wget: for u in $urls; do wget "$u" done But I want to know which URLs to retry again later: retry_later="" for u in $urls; do wget "$u" || retry_later="$retry_later $u" done I can do this, because I know that wget will "succeed" if it gets the file, and "fail" if it doesn't-get the file. I don't have to know what specific values it returns, and I don't really care in this case. And if I want to switch to using Luke Mewburn's ftp instead of wget, I just do: lukemftp "$u" || retry_later="$retry_later $u" and so on and so forth. And then I try the billreid downloader, and whaddya know. He returns "success" whether or not he succeeds, so with his program, I have to do: >/path/to/billreid.logfile billreidget "$u" if grep -q "FAILED" /path/to/billreid.logfile; then retry_later="$retry_later $u" fi ... which works, because I know that grep will indicate success or failure appropriately. The thing is, in the real world, people will sometimes do stuff like # see whether we can grab specification file if wget "$specfile_url"; then program_robot "$specfile" fi because they know that they'll know whether the application succeeded or failed. And if someone then comes in and says "I'll return success unless there was a system error of some sort, even if I do not actually succeed in achieving the task I was assigned, because I can just look in the log files", someone ends up programming the robot with stale data, or a corrupted file, or... And yes, we mostly know better, and people are usually pretty careful with this kind of thing. Usually. But there are people killed every year because software fails, and software fails in part because people don't do error checking, and they don't do error checking because people think it's hilarious overdramatization to imagine that anyone could actually be hurt if you don't check errors or provide the error indicators that people would be checking for... But a big part of the problem is that you're expecting a language standard to dictate terms to operating systems, when it actually goes the other way; operating systems dictate what can be implemented on them, language standards look for things they can expect everyone to provide some way of handling. Virtually all operating systems can distinguish in some way between "success" and "failure" of a program. If you need more than that, you are outside what a language standard can possibly specify, because not all operating systems have more than that. So, again: If you want more information than this, go read the specs for the operating system or systems you care about, but it's not going to be a feature of this language or any other, because languages don't get to decide what operating systems do or don't support. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | Bill Reid <hormelfree@gmail.com> |
|---|---|
| Date | 2011-11-03 17:57 -0700 |
| Message-ID | <16693c4a-df2c-4b6d-8c7e-af995c1ed4e3@h5g2000vbf.googlegroups.com> |
| In reply to | #12640 |
On Nov 3, 3:53 pm, Seebs <usenet-nos...@seebs.net> wrote: > On 2011-11-03, Bill Reid <hormelf...@gmail.com> wrote: > > > Hmmmm, "if you use a command as a conditional", you mean > > like a shell script? OK, maybe we're getting a little > > closer...maybe... > > Yes. > > > OK, maybe I'll answer the question myself, since you're > > having some problems doing so... > > Er, what? > > > on the "TRUE" Unix(TM) I > > worked with for years, there was this circular log that > > kept track of all the apps that were launched on the system, > > and one of the columns in the table showed the exit status > > of the app...simple enough? Sys admins could peruse this > > log and maybe glean some type of insight into how the > > system was working and being used... > > Yup. > > > The problem is, the fact that an application developer > > chose to return a particular value doesn't really say > > a hell of lot about the system function, so I doubt sys > > admins really paid much attention to that column. > > They may have paid attention sometimes. > > > Now if there were a RULE that EXIT_FAILURE would only > > be set for what could be considered system problems during > > the running of an app, such as failure to allocate memory, > > the log would be a lot more useful... > > That would not be a suitable rule for a language standard. It might > be a suitable rule for an operating system standard. > OK, sure, that's why various operating systems have error logging standards baked in...so what was the friggin' point of putting in a largely useless return value in the "C" standard? > It would be a spectacularly stupid rule, though, because there are > widespread systems which have very well established rules for such > behavior. > I'm not sure I'm following...it's stupid because it's a feature of widespread systems? Is this a back-handed MS slam? But I GUESS what you're TRYING to say is that the return value of main() has no particular use because the OS either does or does not supply useful error logging, but the ANSI C committee put it in the standard for writing scripts based on relatively small C programs used as commands and basically no other purpose...maybe they should have stated THAT as their "rationale" (did they?), which would supply some actual guidance as to under what circumstances you should set a particular value... > > but the "C" standard > > is mute on the topic > > As it should be. If you want to do something more specific, you need to > do it in a way specific to your environment. > Or do it myself... > > as are the people who claim that > > incorrect return values COULD KILL PEOPLE DAMMIT!!!! > > That's because we're talking about what actually happens in computers, > not what would have been an interesting alternative design to consider > in a parallel universe where neither Windows nor Unix existed. > No, we're not, you had your chance to prove a certain return value could kill people, particularly without a clear "intervening event" like some goofball writing some dumb script that launches nuclear missiles because he thinks that somebody is following a rule that he already knows a lot of people don't follow... > > No, not that hilarious, just pointing out you were > > indulging in some unwarranted fear-mongering... > > Except that it's not unwarranted. > Yes it is...extraordinary claims require extraordinary proof, you provided nothing other than hand-waving... > > and > > you felt free to continue in that vein, even after > > being laughed at about it: > > That's because the "being laughed at" was stupid and ignorant. > What have I written that would lead you to conclude I was either stupid or ignorant, other than it is fun to insult people who share different, possibly more correct, opinions than you? > > Yes, ASSUMPTIONS are the key to what I'm asking > > about, DAMMIT!!! > > Maybe you should focus less on being a jerk and more on articulating > your questions, then? > What have I written that would lead you to posit I have not asked clear articulate questions? You snipping them out and answering questions of your own liking does not count... > > Objection, motion to strike, argumentative, unresponsive, > > irrelevant... > > So you weren't actually asking the question you asked. > Sorry, been watching the late afternoon Conrad Murray trial on TV, you just seem to be out of order on this topic... > > Maybe your post should return "EXIT_TAUTOLOGY"; everything > > just refers back to the "C" standard, and yet what I asked > > about is how the "C" standard can control the behavior of > > various operating systems when it can't even specify what > > the behavior of an application developer should be in returning > > a SPECFIC value to the operating system... > > Okay, you seem to be under some kind of strange delusions about the > relationship of a language standard to the rest of the world. > Well, that makes two of us, since I think we're in total agreement that a language standard cannot control the OS...so what was the point of passing a binary value to the OS again? Basically scripts? > Operating systems exist, and have requirements that vary based on > what they are operating systems for. Or the whims and/or stupidity of the OS designers... > Language specs don't get to > control that. Language specs offer limited standardized functionality, > and if you need functionality beyond what they can offer, you have to > go look at other specs. > Sure...but hey, think about this: instead of a binary value for main(), allow the full use of the int to allow OS-specified return values that would actually mean something...sound reasonable? Just an idea...probably IS stupid... > If you want the *portable* C answer, the only values that mean anything > are 0, EXIT_SUCCESS, and EXIT_FAILURE, and there is no guarantee that > every operating system everywhere does anything with them. Whew...your logic does not resemble our Earth logic...I'm not even going to try on this one, it'd be like debating the crazy homeless guy shouting to himself on the street corner... > However, > realistically, any implementation that's hosted will at the very least do > something vaguely reasonable with these. > I was previously not amused with your use of the term "hosted" in relation to Windows(TM), and it's not getting any funnier... > If you want an answer that's more specific to a platform, then your > answer necessarily depends on the specifics of that platform and > environment. > > > It's about one of the most frequently answered questions > > here (right up there with not casting the return value of > > malloc())!!! > > The winmain() question isn't. > > > How can it NOT be topical, IT'S ALWAYS BROUGHT > > UP WHETHER ASKED FOR OR NOT!!??!!! > > It can not be topical because it turns out to be a question about specific > operating systems, to which different systems have different answers, not > a question about the language. > I guess it's always a question about pointless pedantry versus real life...on a scale of 0 to 100 of possible PROGRAMMER errors, "misuse" of the return value of main() is about a 0.0000000025, and cannot reasonably foreseeably kill anybody. You've only been told this about 8 billion times, you might just concede that simple point and move along to something slightly more important, like the precise average amount of lint your navel collects in a day... > > I'm 100% serious because when I program an effin' > > computer I expect "hospital corners" for every effin' > > thing I do...if I do something, I want to know EXACTLY > > how it will impact the system and my application and > > my users > > Then you'd be well served by learning that a computer system is more than > one thing. The language is not the same thing as the operating system, > which is not the same thing as the hardware. If you want to know what > specific return values do, look at the operating system, because that's what > is doing something with them. > EXACTLY. You've once again managed to expertly beg the question, just like the crazy homeless guy begs for money... > > I'm reading, so here's a scenario: one application I wrote > > automatically downloads hundreds of files a day from all over > > the Internet, different web-sites, different formats, etc. > > That's nice. > What's really nice is another snip-a-roo so you could do the following pointless "fancy footwork": > > Both of those could be considered "failures" of > > the application to do what I wanted it to do; so > > should I set "EXIT_FAILURE"? > > That is up to you and your feelings about what your specific operating > system does with the values. > No it isn't; what you snipped out was just the tip of the iceberg of my program requirements...the OS very kindly logs various types of Internet failures, but I have to parse them to get to what I need to do, and I have to do a whole lot more and of course this has NOTHING to do with the return value of main()... > > (And just to cut to > > the chase, I don't, I handle stuff like that, and > > Internet connectivity problems, etc., in my own application > > "logs", and would only use "EXIT_FAILURE" for something > > like a failure to allocate, even though I have no > > idea what PRACTICAL benefit that provides me, > > since that is separately logged as well.) > > The main practical benefit is that it offers other programs a way to > find out whether your program worked without needing to know that much > about your program. > I as a person, both as the user of the program and person who wrote to the program to do certain things, have no need or desire to know whether my program "worked" or not, but I have a burning need to know exactly WHY it didn't WORK (you know, what you disingenuously snipped out). > Let's say I want to grab a bunch of files. Right now, I'm using wget: > for u in $urls; do > wget "$u" > done > What do they call this, "script kiddie" work? Yeah, I've used that command, and I guess I could have used it in a script to do what I wanted to do...as long as the script was about 10 times as long as this friggin' long post... > But I want to know which URLs to retry again later: > > retry_later="" > for u in $urls; do > wget "$u" || retry_later="$retry_later $u" > done > See, it's getting longer already...now make it do the downloads according to dozens of different schedules, making sure that it actually has the right files, you know, the stuff you snipped out, along with automatically placing the files in hundreds of different directories according to the types of data, then invoking a hundred or so file parsing routines to pull the wanted data out and loaded automatically into my database, you know, stuff like that...when do you think you'll have my script ready? > I can do this, because I know that wget will "succeed" if it gets the > file, and "fail" if it doesn't-get the file. I don't have to know what > specific values it returns, and I don't really care in this case. See, I actually kind of care, but you may have a point, if you don't get your file, try, try again, and don't worry if the file is corrupt, just go ahead and download it anyway, it's easier to fix a corrupted database days or weeks later if you're not aware of it at download... > And > if I want to switch to using Luke Mewburn's ftp instead of wget, I just do: > > lukemftp "$u" || retry_later="$retry_later $u" > > and so on and so forth. > > And then I try the billreid downloader, and whaddya know. He returns > "success" whether or not he succeeds, so with his program, I have to do: > > >/path/to/billreid.logfile > billreidget "$u" > if grep -q "FAILED" /path/to/billreid.logfile; then > retry_later="$retry_later $u" > fi > > ... which works, because I know that grep will indicate success or failure > appropriately. > Yeah, I guess we work on two entirely different levels of software... > The thing is, in the real world, people will sometimes do stuff like > # see whether we can grab specification file > if wget "$specfile_url"; then > program_robot "$specfile" > fi > > because they know that they'll know whether the application succeeded or > failed. > > And if someone then comes in and says "I'll return success unless there was > a system error of some sort, even if I do not actually succeed in achieving > the task I was assigned, because I can just look in the log files", someone > ends up programming the robot with stale data, or a corrupted file, or... > Yeah, that was exactly why I don't use the "script kiddie" approach, I'm watching a scheduled download now, it's giving me all the information on success or failure, a few days ago one of the "5pm weekdays except certain holidays" files was retitled and I got an error message, which automatically pulled up the file so I could get the new title string, I selected the download configuration menu item and replaced the string to look for with the new one and now I don't get the message anymore...sure am sorry I don't rely on the return value of main()... > And yes, we mostly know better, and people are usually pretty careful with > this kind of thing. Usually. But there are people killed every year > because software fails, and software fails in part because people don't > do error checking, and they don't do error checking because people think > it's hilarious overdramatization to imagine that anyone could actually be > hurt if you don't check errors or provide the error indicators that people > would be checking for... > Give it up...I've told you at least a dozen effin' times my goal is to get much more PRECISE error messages to avoid any type of unwanted error, and I just don't get that from main()...aren't you worried that you're confusing the "children", or is that your goal? > But a big part of the problem is that you're expecting a language standard > to dictate terms to operating systems, when it actually goes the other way; > operating systems dictate what can be implemented on them, language standards > look for things they can expect everyone to provide some way of handling. Nope. If it's undefined, it's a waste of time, and the return value of main() is for all practical intents and purposes undefined, except for "script kiddies"... > Virtually all operating systems can distinguish in some way between > "success" and "failure" of a program. Sure, "running" or "not responding" seem to be popular... > If you need more than that, you are > outside what a language standard can possibly specify, because not all > operating systems have more than that. > Well, sure, and in many cases I have to provide it myself, maybe just for the sake of the holy "portability" (remember, my own error logging written in "C" is fully portable as long as it doesn't rely on OS-specific logging)... > So, again: If you want more information than this, go read the specs for > the operating system or systems you care about, but it's not going to be > a feature of this language or any other, because languages don't get to > decide what operating systems do or don't support. > EXACTLY. Thanks for agreeing with me, AND for calling me an "idiot" and "ignorant" in the process... --- William Ernest Reid
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2011-11-03 21:35 -0500 |
| Message-ID | <mui6b793ee2k13c5lnqlknbh1ndd7fa9d7@4ax.com> |
| In reply to | #12649 |
On Thu, 3 Nov 2011 17:57:27 -0700 (PDT), Bill Reid
<hormelfree@gmail.com> wrote:
>On Nov 3, 3:53 pm, Seebs <usenet-nos...@seebs.net> wrote:
>I'm not sure I'm following...it's stupid because it's a feature
>of widespread systems? Is this a back-handed MS slam?
>
>But I GUESS what you're TRYING to say is that the return
>value of main() has no particular use because the OS either
>does or does not supply useful error logging, but the ANSI
>C committee put it in the standard for writing scripts based
>on relatively small C programs used as commands and basically
>no other purpose...maybe they should have stated THAT as their
>"rationale" (did they?), which would supply some actual guidance as
>to under what circumstances you should set a particular value...
I'm not sure how much of this is sarcasm, but small integer return
values being passed back from programs to the script (we called it JCL
way back then) dates back to at least the late 50s. The exact meaning
has always varied between systems, but essentially all systems have at
least distinguished between success and failure is some semi-regular
way.
Nor is failure really that narrow a concept - the program failed to
compile - the JCL should terminate the compile job at that point and
not link and overlay the old executable. Or the make utility should
do something similar.
>Sure...but hey, think about this: instead of a binary value for
>main(), allow the full use of the int to allow OS-specified return
>values that would actually mean something...sound reasonable? Just
>an idea...probably IS stupid...
But the return value of main() is not binary, ANSI just standardized
ways of generically specifying success and failure. The meaning of
any other value is implementation defined (not undefined).
There are many parts of the standard which are implementation defined,
particularly when it comes to interfacing to the system - the syntax
of filenames, for example. The exact meaning of exit(3) is as
implementation specific as the meaning of fopen("lpt1:", "w").
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-11-04 03:31 +0000 |
| Message-ID | <slrnjb6mst.781.usenet-nospam@guild.seebs.net> |
| In reply to | #12651 |
On 2011-11-04, Robert Wessel <robertwessel2@yahoo.com> wrote:
> But the return value of main() is not binary, ANSI just standardized
> ways of generically specifying success and failure. The meaning of
> any other value is implementation defined (not undefined).
Right. And the thing is... Some systems let you return anything you want.
Some do things like filtering it down to an 8-bit value, or whatever else.
But this is *beyond what the language can control*.
> There are many parts of the standard which are implementation defined,
> particularly when it comes to interfacing to the system - the syntax
> of filenames, for example. The exact meaning of exit(3) is as
> implementation specific as the meaning of fopen("lpt1:", "w").
Exactly. This is in the same category of stuff as the file interface.
The C standard carefully doesn't specify the form of file names... But any
*given* implementation will, and will usually do it usefully.
-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-11-04 02:25 -0700 |
| Message-ID | <9bc32d75-9425-4dd6-87dc-1df7ddb327ca@gy7g2000vbb.googlegroups.com> |
| In reply to | #12649 |
On Nov 4, 12:57 am, Bill Reid <hormelf...@gmail.com> wrote: > On Nov 3, 3:53 pm, Seebs <usenet-nos...@seebs.net> wrote: > > On 2011-11-03, Bill Reid <hormelf...@gmail.com> wrote: > OK, sure, that's why various operating systems have error > logging standards baked in...so what was the [quasi-expletive] point > of putting in a largely useless return value in the "C" standard? why is a success/failure indication useless? Millions of Unix scipts use it every day. If the file failed to copy then we give up or try to get the important value from somewhere else. If you don't care if your program fails do you care if anything fails? Does your progarm have any error handling? read RISKS for some interesting results of poor error handling. Ah. Backup. I suspect some (rather noddy) backup systems on unix are based on tar then cp. If one of these fails but the failure was ignored you might *think* your files were backed up. I'll leave you to worry what data loss might do. <snip rant>
[toc] | [prev] | [next] | [standalone]
| From | Kulin Remailer <remailer@reece.net.au> |
|---|---|
| Date | 2011-11-03 22:47 +0000 |
| Message-ID | <09OJOGAJ40851.2831365741@reece.net.au> |
| In reply to | #12612 |
> > 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? On the OS I work on (not a PC OS) every program is supposed to set a return code. It doesn't matter if it's a main program or a subprogram (nor should it, since today's main program may be tomorrow's subprogram and today's subprogram may be tomorrow's main program). Also, and this is a big difference from UNIX/Linux the return codes are /fully documented/. I know that last part is a big shocker, but yeah, code worth writing to sell to people is code that needs to give good messages and documented meaningful return codes. Actually, our convention on that OS is to give two types of codes, a reason code and a return code and those are standardized with groups of normal, warning, error, severe error, etc. return code and then a reason code that specifies, within that category, the reason for the error. We don't give error messages like opps, sorry, etc. Do yourself and everybody else a favor. Set return codes and document them. It's the Right Thing To Do.
[toc] | [prev] | [next] | [standalone]
| From | Bill Reid <hormelfree@gmail.com> |
|---|---|
| Date | 2011-11-03 16:14 -0700 |
| Message-ID | <5f943fd6-f5f1-4859-83c0-3c84c537c2f5@t8g2000yql.googlegroups.com> |
| In reply to | #12637 |
On Nov 3, 3:47 pm, Kulin Remailer <remai...@reece.net.au> 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? > > On the OS I work on (not a PC OS) every program is supposed to set a return > code. It doesn't matter if it's a main program or a subprogram (nor should > it, since today's main program may be tomorrow's subprogram and today's > subprogram may be tomorrow's main program). Also, and this is a big > difference from UNIX/Linux the return codes are /fully documented/. I know > that last part is a big shocker, but yeah, code worth writing to sell to > people is code that needs to give good messages and documented meaningful > return codes. Actually, our convention on that OS is to give two types of > codes, a reason code and a return code and those are standardized with > groups of normal, warning, error, severe error, etc. return code and then a > reason code that specifies, within that category, the reason for the error. > > We don't give error messages like opps, sorry, etc. Do yourself and > everybody else a favor. Set return codes and document them. It's the Right > Thing To Do. Yeah, that's just ter-rrrrrific, but again, you're missing the point, which was about the return value of main(), which is a mere binary value indicating "success" or "failure" without any explanation of what constitutes "success" or "failure"... Now as to other errors that may be logged on various systems as an application is running, as you describe, a system may have a very robust (or not!) system of error logging, but this has nothing to do with the ANSI C standard-specified values from main(). Rather these are usually system-specific and hard to port from system to system without substantial compatibility library work or some-such, and thus represent perhaps the greatest challenge to portability of "C" and other languages below the GUI level... --- William Ernest Reid
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2011-11-03 21:55 -0500 |
| Message-ID | <lvj6b7pn1odro7alf3085mg6nbgb15t3ce@4ax.com> |
| In reply to | #12612 |
On 03 Nov 2011 18:35:58 GMT, Seebs <usenet-nospam@seebs.net> wrote: >That would be traditional Windows being what is called a "freestanding >environment", which is to say, one which doesn't conform to the C standard's >rules for a "hosted" environment. Normally, a "freestanding environment" >is used for something like a tiny embedded board with little to no operating >system. One of the interesting side effects was that some Windows compilers >chose not to offer a working <stdio.h> or the related functionality when >they were used in the mode where they started execution at winmain(). >(I believe I've seen claims that at least one omitted *sprintf* too in >this mode. Which is allowed, and goes to show why you always want a >hosted implementation if possible.) If any of MS's versions of C for Windows omitted sprintf(), they have to date back to before Win3.0. What was an issue was that Win16 programs mostly used a mixed memory model. Most applications were compiled as "medium" model*, thus had "near" (16-bit) pointers for conventional C data items. But Windows, and communications with other modules often required "far" (32-bit) pointers. For passing local data to prototyped function, this was a non-issue, since near pointers would automatically get widened when passed for a parameter specified as a far pointer. For things like sprintf() or strcpy(), you could pass pointers to local items, but not stuff you got from outside your application, since the pointers would be truncated (in the case of sprintf() - strcpy() was more likely to fail to compile). So Windows provided alternate versions (wsprintf(), _fstrcpy(), etc.) that accepted far pointers even in medium model. But regular old strcpy() was there, just not that useful in Win16. *"Large" model applications took a significant performance hit because of segmentation on CPUs.
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web