Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #21522 > unrolled thread
| Started by | mike3 <mike4ty4@yahoo.com> |
|---|---|
| First post | 2012-05-29 22:44 -0700 |
| Last post | 2012-06-06 08:12 -0700 |
| Articles | 20 on this page of 133 — 38 participants |
Back to article view | Back to comp.lang.c
Error returns and repeated code, GOTOs, etc. mike3 <mike4ty4@yahoo.com> - 2012-05-29 22:44 -0700
Re: Error returns and repeated code, GOTOs, etc. Ike Naar <ike@sverige.freeshell.org> - 2012-05-30 06:38 +0000
Re: Error returns and repeated code, GOTOs, etc. Nils M Holm <news2009@t3x.org> - 2012-05-30 06:57 +0000
Re: Error returns and repeated code, GOTOs, etc. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-05-30 00:52 -0700
Re: Error returns and repeated code, GOTOs, etc. mike3 <mike4ty4@yahoo.com> - 2012-05-30 01:50 -0700
Re: Error returns and repeated code, GOTOs, etc. MarkBluemel <mark_bluemel@pobox.com> - 2012-05-30 09:55 +0100
Re: Error returns and repeated code, GOTOs, etc. Willem <willem@toad.stack.nl> - 2012-05-30 09:18 +0000
Re: Error returns and repeated code, GOTOs, etc. tom st denis <tom@iahu.ca> - 2012-05-30 05:16 -0700
Re: Error returns and repeated code, GOTOs, etc. Willem <willem@toad.stack.nl> - 2012-05-30 16:26 +0000
Re: Error returns and repeated code, GOTOs, etc. tom st denis <tom@iahu.ca> - 2012-06-01 08:05 -0700
Re: Error returns and repeated code, GOTOs, etc. Willem <willem@toad.stack.nl> - 2012-06-03 11:24 +0000
Re: Error returns and repeated code, GOTOs, etc. jgk@panix.com (Joe keane) - 2012-06-02 13:54 +0000
Re: Error returns and repeated code, GOTOs, etc. Jean-Christophe <5.d@free.fr> - 2012-06-02 07:24 -0700
Re: Error returns and repeated code, GOTOs, etc. jgk@panix.com (Joe keane) - 2012-06-02 16:37 +0000
Re: Error returns and repeated code, GOTOs, etc. Jean-Christophe <5.d@free.fr> - 2012-06-02 12:46 -0700
Re: Error returns and repeated code, GOTOs, etc. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-02 15:42 +0100
Re: Error returns and repeated code, GOTOs, etc. jgk@panix.com (Joe keane) - 2012-06-02 19:35 +0000
Re: Error returns and repeated code, GOTOs, etc. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-03 03:53 +0100
Re: Error returns and repeated code, GOTOs, etc. Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-06-11 18:10 +0300
Re: Error returns and repeated code, GOTOs, etc. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-11 16:19 +0100
Re: Error returns and repeated code, GOTOs, etc. Martin Shobe <martin.shobe@yahoo.com> - 2012-06-02 19:27 +0000
Re: Error returns and repeated code, GOTOs, etc. jgk@panix.com (Joe keane) - 2012-06-03 23:48 +0000
Re: Error returns and repeated code, GOTOs, etc. Ian Collins <ian-news@hotmail.com> - 2012-06-04 11:53 +1200
Re: Error returns and repeated code, GOTOs, etc. Martin Shobe <martin.shobe@yahoo.com> - 2012-06-04 03:32 +0000
Re: Error returns and repeated code, GOTOs, etc. nick_keighley_nospam@hotmail.com - 2012-05-30 07:25 -0700
Re: Error returns and repeated code, GOTOs, etc. falk@rahul.net (Edward A. Falk) - 2012-06-05 07:20 +0000
Re: Error returns and repeated code, GOTOs, etc. Ian Collins <ian-news@hotmail.com> - 2012-05-30 21:50 +1200
Re: Error returns and repeated code, GOTOs, etc. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-05-30 03:34 -0700
Re: Error returns and repeated code, GOTOs, etc. Ian Collins <ian-news@hotmail.com> - 2012-05-30 22:57 +1200
Re: Error returns and repeated code, GOTOs, etc. Willem <willem@toad.stack.nl> - 2012-05-30 11:04 +0000
Re: Error returns and repeated code, GOTOs, etc. nick_keighley_nospam@hotmail.com - 2012-05-30 04:53 -0700
Re: Error returns and repeated code, GOTOs, etc. "BartC" <bc@freeuk.com> - 2012-05-30 13:28 +0100
Re: Error returns and repeated code, GOTOs, etc. mike3 <mike4ty4@yahoo.com> - 2012-05-30 13:57 -0700
Re: Error returns and repeated code, GOTOs, etc. "io_x" <a@b.c.invalid> - 2012-05-30 15:19 +0200
Re: Error returns and repeated code, GOTOs, etc. Mark Bluemel <mark.bluemel@googlemail.com> - 2012-05-31 01:10 -0700
Re: Error returns and repeated code, GOTOs, etc. "io_x" <a@b.c.invalid> - 2012-06-02 17:34 +0200
Re: Error returns and repeated code, GOTOs, etc. "io_x" <a@b.c.invalid> - 2012-06-03 10:33 +0200
Re: Error returns and repeated code, GOTOs, etc. Ike Naar <ike@iceland.freeshell.org> - 2012-05-30 13:56 +0000
Re: Error returns and repeated code, GOTOs, etc. Kulin <remailer@reece.net.au> - 2012-05-30 17:29 +0000
Re: Error returns and repeated code, GOTOs, etc. ImpalerCore <jadill33@gmail.com> - 2012-05-30 07:13 -0700
Re: Error returns and repeated code, GOTOs, etc. Thad Smith <ThadSmith@acm.org> - 2012-06-02 07:20 -0600
Re: Error returns and repeated code, GOTOs, etc. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-30 16:37 +0100
Re: Error returns and repeated code, GOTOs, etc. Johann Klammer <klammerj@NOSPAM.a1.net> - 2012-05-30 19:05 +0200
Re: Error returns and repeated code, GOTOs, etc. Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-31 13:19 -0700
Re: Error returns and repeated code, GOTOs, etc. mike3 <mike4ty4@yahoo.com> - 2012-05-31 13:49 -0700
Re: Error returns and repeated code, GOTOs, etc. "BartC" <bc@freeuk.com> - 2012-05-31 22:08 +0100
Re: Error returns and repeated code, GOTOs, etc. mike3 <mike4ty4@yahoo.com> - 2012-05-31 16:08 -0700
Re: Error returns and repeated code, GOTOs, etc. Tim Rentsch <txr@alumni.caltech.edu> - 2012-05-31 17:34 -0700
Re: Error returns and repeated code, GOTOs, etc. Willem <willem@toad.stack.nl> - 2012-06-01 07:40 +0000
GOTOs discovered in "real world" program! (was Re: Error returns and repeated code, GOTOs, etc.) mike3 <mike4ty4@yahoo.com> - 2012-05-31 16:39 -0700
Re: GOTOs discovered in "real world" program! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-01 03:21 +0100
Re: GOTOs discovered in "real world" program! mike3 <mike4ty4@yahoo.com> - 2012-06-01 03:49 -0700
Re: GOTOs discovered in "real world" program! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-02 02:15 +0100
Re: GOTOs discovered in "real world" program! mike3 <mike4ty4@yahoo.com> - 2012-06-01 19:45 -0700
Re: GOTOs discovered in "real world" program! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-02 15:00 +0100
Re: GOTOs discovered in "real world" program! mike3 <mike4ty4@yahoo.com> - 2012-06-02 16:44 -0700
Re: GOTOs discovered in "real world" program! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-03 03:51 +0100
Re: GOTOs discovered in "real world" program! "Aaron W. Hsu" <arcfide@sacrideo.us> - 2012-06-01 12:06 -0400
Re: GOTOs discovered in "real world" program! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-02 02:01 +0100
Re: GOTOs discovered in "real world" program! mike3 <mike4ty4@yahoo.com> - 2012-06-01 19:46 -0700
Re: GOTOs discovered in "real world" program! mike3 <mike4ty4@yahoo.com> - 2012-06-01 21:19 -0700
Re: GOTOs discovered in "real world" program! blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2012-06-02 16:35 +0000
Re: GOTOs discovered in "real world" program! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-02 14:50 +0100
Re: GOTOs discovered in "real world" program! Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-06-02 07:04 -0700
Re: GOTOs discovered in "real world" program! "Aaron W. Hsu" <arcfide@sacrideo.us> - 2012-06-02 04:37 -0500
Re: GOTOs discovered in "real world" program! mike3 <mike4ty4@yahoo.com> - 2012-06-02 03:40 -0700
Re: GOTOs discovered in "real world" program! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-02 14:46 +0100
Re: GOTOs discovered in "real world" program! "BartC" <bc@freeuk.com> - 2012-06-02 17:10 +0100
Re: GOTOs discovered in "real world" program! Robert Wessel <robertwessel2@yahoo.com> - 2012-06-02 11:35 -0500
Re: GOTOs discovered in "real world" program! (was Re: Error returns and repeated code, GOTOs, etc.) "BartC" <bc@freeuk.com> - 2012-06-02 09:46 +0100
Re: GOTOs discovered in "real world" program! (was Re: Error returns and repeated code, GOTOs, etc.) "io_x" <a@b.c.invalid> - 2012-06-03 10:43 +0200
Re: GOTOs discovered in "real world" program! (was Re: Error returns and repeated code, GOTOs, etc.) "BartC" <bc@freeuk.com> - 2012-06-03 10:58 +0100
Re: GOTOs discovered in "real world" program! (was Re: Error returns and repeated code, GOTOs, etc.) "io_x" <a@b.c.invalid> - 2012-06-03 17:18 +0200
Re: GOTOs discovered in "real world" program! (was Re: Error returns and repeated code, GOTOs, etc.) jgk@panix.com (Joe keane) - 2012-06-04 20:40 +0000
Re: GOTOs discovered in "real world" program! (was Re: Error returns and repeated code, GOTOs, etc.) jgk@panix.com (Joe keane) - 2012-06-05 01:03 +0000
Re: GOTOs discovered in "real world" program! Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-06-04 21:36 -0600
Re: GOTOs discovered in "real world" program! jgk@panix.com (Joe keane) - 2012-06-05 15:13 +0000
Re: GOTOs discovered in "real world" program! (was Re: Error returns and repeated code, GOTOs, etc.) Ike Naar <ike@sverige.freeshell.org> - 2012-06-05 08:12 +0000
Re: GOTOs discovered in "real world" program! (was Re: Error returns and repeated code, GOTOs, etc.) James Kuyper <jameskuyper@verizon.net> - 2012-06-05 06:00 -0400
Re: GOTOs discovered in "real world" program! (was Re: Error returns and repeated code, GOTOs, etc.) jgk@panix.com (Joe keane) - 2012-06-05 02:05 +0000
Re: GOTOs discovered in "real world" program! (was Re: Error returns and repeated code, GOTOs, etc.) Martin Shobe <martin.shobe@yahoo.com> - 2012-06-05 03:16 +0000
Re: GOTOs discovered in "real world" program! (was Re: Error returns and repeated code, GOTOs, etc.) "io_x" <a@b.c.invalid> - 2012-06-03 17:30 +0200
Re: GOTOs discovered in "real world" program! (was Re: Error returns and repeated code, GOTOs, etc.) Jean-Christophe <5.d@free.fr> - 2012-06-03 09:02 -0700
Re: GOTOs discovered in "real world" program! (was Re: Error returns and repeated code, GOTOs, etc.) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-03 22:37 +0100
Re: GOTOs discovered in "real world" program! (was Re: Error returns and repeated code, GOTOs, etc.) Ike Naar <ike@iceland.freeshell.org> - 2012-06-04 07:28 +0000
Re: GOTOs discovered in "real world" program! (was Re: Error returns and repeated code, GOTOs, etc.) Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-08 01:28 -0700
Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) mike3 <mike4ty4@yahoo.com> - 2012-06-06 02:54 -0700
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-06 13:14 +0100
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) pete <pfiland@mindspring.com> - 2012-06-06 09:22 -0400
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) Willem <willem@toad.stack.nl> - 2012-06-06 13:49 +0000
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) Rui Maciel <rui.maciel@gmail.com> - 2012-06-06 14:56 +0100
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) James Kuyper <jameskuyper@verizon.net> - 2012-06-06 10:17 -0400
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) Angel <angel+news@spamcop.net> - 2012-06-06 13:06 +0000
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) mike3 <mike4ty4@yahoo.com> - 2012-06-07 16:26 -0700
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) Angel <angel+news@spamcop.net> - 2012-06-08 14:26 +0000
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) mike3 <mike4ty4@yahoo.com> - 2012-06-08 15:19 -0700
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) Angel <angel+news@spamcop.net> - 2012-06-08 23:32 +0000
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) "BartC" <bc@freeuk.com> - 2012-06-09 01:14 +0100
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) Jean-Christophe <5.d@free.fr> - 2012-06-09 04:36 -0700
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-06-09 05:54 -0700
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) "BartC" <bc@freeuk.com> - 2012-06-09 16:12 +0100
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-06-09 08:44 -0700
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) "io_x" <a@b.c.invalid> - 2012-06-10 18:23 +0200
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) "io_x" <a@b.c.invalid> - 2012-06-10 19:42 +0200
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) "io_x" <a@b.c.invalid> - 2012-06-14 18:00 +0200
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) nick_keighley_nospam@hotmail.com - 2012-06-11 01:14 -0700
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) "io_x" <a@b.c.invalid> - 2012-06-12 08:01 +0200
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) nick_keighley_nospam@hotmail.com - 2012-06-12 05:27 -0700
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) "io_x" <a@b.c.invalid> - 2012-06-12 08:44 +0200
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) jgk@panix.com (Joe keane) - 2012-06-11 17:24 +0000
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) "BartC" <bc@freeuk.com> - 2012-06-11 19:02 +0100
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) jgk@panix.com (Joe keane) - 2012-06-12 20:03 +0000
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) nick_keighley_nospam@hotmail.com - 2012-06-13 00:58 -0700
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) James Kuyper <jameskuyper@verizon.net> - 2012-06-13 06:37 -0400
Evil in Programming Was: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) nick_keighley_nospam@hotmail.com - 2012-06-13 04:50 -0700
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) gwowen <gwowen@gmail.com> - 2012-06-13 07:02 -0700
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) Les Cargill <lcargill99@comcast.com> - 2012-06-13 12:47 -0500
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) James Kuyper <jameskuyper@verizon.net> - 2012-06-13 14:17 -0400
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) Willem <willem@toad.stack.nl> - 2012-06-13 19:44 +0000
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) James Kuyper <jameskuyper@verizon.net> - 2012-06-13 15:52 -0400
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) Les Cargill <lcargill99@comcast.com> - 2012-06-13 17:45 -0500
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) James Kuyper <jameskuyper@verizon.net> - 2012-06-13 19:07 -0400
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) jgk@panix.com (Joe keane) - 2012-06-14 23:03 +0000
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) Kaz Kylheku <kaz@kylheku.com> - 2012-06-14 23:25 +0000
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) Les Cargill <lcargill99@comcast.com> - 2012-06-14 19:25 -0500
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) 88888 Dihedral <dihedral88888@googlemail.com> - 2012-06-17 20:32 -0700
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) nick_keighley_nospam@hotmail.com - 2012-06-18 01:30 -0700
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) Les Cargill <lcargill99@comcast.com> - 2012-06-18 07:06 -0500
Re: Why was there a GOTO? Gareth Owen <gwowen@gmail.com> - 2012-06-13 19:57 +0100
Re: Why was there a GOTO? (was Re: GOTOs discovered in "real world" program!) jgk@panix.com (Joe keane) - 2012-06-10 16:56 +0000
Another problem (was Re: Error returns and repeated code, GOTOs, etc.) mike3 <mike4ty4@yahoo.com> - 2012-05-31 16:46 -0700
Re: Another problem (was Re: Error returns and repeated code, GOTOs, etc.) Ian Collins <ian-news@hotmail.com> - 2012-06-01 15:55 +1200
Re: Error returns and repeated code, GOTOs, etc. gwowen <gwowen@gmail.com> - 2012-06-06 08:12 -0700
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | Thad Smith <ThadSmith@acm.org> |
|---|---|
| Date | 2012-06-02 07:20 -0600 |
| Message-ID | <jqd3v2$fsl$1@speranza.aioe.org> |
| In reply to | #21544 |
On 5/30/2012 8:13 AM, ImpalerCore wrote: > On a side note, the term ERROR_SUCCESS appears contradictory to me. I > would prefer something like NO_ERROR or SUCCESS if you had control > over the error definitions. I agree. With an ERROR prefix I would use ERROR_NONE. My preference, though, is to use <module>_SUCCESS (or <module>_OK), where <module> is replaced by a name that designates the particular module whose status is being reported. Thad
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-05-30 16:37 +0100 |
| Message-ID | <0.6c4495da7de45523cb1d.20120530163742BST.87obp5bry1.fsf@bsb.me.uk> |
| In reply to | #21522 |
mike3 <mike4ty4@yahoo.com> writes:
> I've got some stuff that looks like this:
<snip code>
Just because no one has yet used an array:
ErrorCode MyFunc(void)
{
enum { a, b, c, d, n_big_nums };
BigNum num[n_big_nums];
ErrorCode rv;
int n = 0;
while (n < n_big_nums && BigNum_Initialize(&num[n]) == ERROR_SUCCESS)
n++;
if (n == n_big_nums)
do {
/* do some math */
rv = BigNum_Set(&num[b], 3);
if (rv != ERROR_SUCCESS)
break;
/* ... */
} while (0);
while (n--)
BigNum_Free(&num[n]);
return rv;
}
You don't have to use the do { ... } while (0); thing. Just add a label
to the end loop and goto it instead of using break.
You have to switch a, b and so on to num[a], num[b] but it does extend
easily if you find you need another BigNum.
(Note that "ErrorCode MyFunc(void)" is a prototype whereas "ErrorCode
MyFunc()" is not.)
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Johann Klammer <klammerj@NOSPAM.a1.net> |
|---|---|
| Date | 2012-05-30 19:05 +0200 |
| Message-ID | <4fc65364$0$18689$91cee783@newsreader03.highway.telekom.at> |
| In reply to | #21522 |
mike3 wrote: [...] > But we've violated Djikstra and we've used a "bad" goto. How would > _you_ write MyFunc() above? Hello, If you want to get rid of the gotos and the ifs, you might end up using some kind of object stack. Every time you create or initialize something, you push a handle and a destructor onto the stack. If something goes wrong, you work your way down the stack destroying all the resources. A bit like pthread_cleanup_push/pop. Of course it is kludgy, may involve unsafe casts and a bit of additional overhead. I do not use it much myself. There is an implementation here: http://members.aon.at/~aklamme4/dvbv/dvbvulture_1.0.23.tar.gz In the files common/custck.c include/custck.h (please ignore the code smell) JK
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2012-05-31 13:19 -0700 |
| Message-ID | <kfnobp4yuh7.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #21522 |
mike3 <mike4ty4@yahoo.com> writes:
> I've got some stuff that looks like this:
>
> ---
> ErrorCode MyFunc()
> {
> BigNum a, b, c, d;
> ErrorCode rv;
>
> rv = BigNum_Initialize(&a);
> if(rv != ERROR_SUCCESS)
> return(rv);
>
> rv = BigNum_Initialize(&b);
> if(rv != ERROR_SUCCESS)
> {
> BigNum_Free(&a); /* and what if THIS fails??? :) */
> return(rv);
> }
>
> rv = BigNum_Initialize(&c);
> if(rv != ERROR_SUCCESS)
> {
> BigNum_Free(&b);
> BigNum_Free(&a);
> return(rv);
> }
>
> rv = BigNum_Initialize(&d);
> if(rv != ERROR_SUCCESS)
> {
> BigNum_Free(&c);
> BigNum_Free(&b);
> BigNum_Free(&a);
> return(rv);
> }
>
> /* do some math */
> rv = BigNum_Set(&b, 3);
> if(rv != ERROR_SUCCESS)
> {
> BigNum_Free(&d);
> BigNum_Free(&c);
> BigNum_Free(&b);
> BigNum_Free(&a);
> return(rv);
> }
>
> ...
>
> /* free buffers */
> rv = BigNum_Free(&d);
> if(rv != ERROR_SUCCESS)
> {
> BigNum_Free(&c);
> BigNum_Free(&b);
> BigNum_Free(&a);
> return(rv);
> }
>
> rv = BigNum_Free(&c);
> if(rv != ERROR_SUCCESS)
> {
> BigNum_Free(&b);
> BigNum_Free(&a);
> return(rv);
> }
>
> rv = BigNum_Free(&b);
> if(rv != ERROR_SUCCESS)
> {
> BigNum_Free(&a);
> return(rv);
> }
>
> rv = BigNum_Free(&a);
> if(rv != ERROR_SUCCESS)
> return(rv);
>
> return(ERROR_SUCCESS);
> }
> ---
>
> But this is nasty, with all those duplicated "free" blocks. What can
> be done to relieve this code duplication? It's ugly, it hurts my
> freaking eyes and my nose is screaming for relief. And it hurts
> maintainability to no end -- what if we decide to add more capability
> to MyFunc() that requires additional bignums? Oy... We'd have to
> update _all those blocks_.
>
> I was thinking about using a "goto", but Gotos are Bad, aren't they? I
> can't believe I may have to use a goto! What about Djikstra's famous
> letter? Is it possible that perhaps a goto may be GOOD here? Because
> with a goto this would all seem much simpler. If we violate Djikstra,
> we get:
>
> ---
>
> ErrorCode MyFunc()
> {
> BigNum a, b, c, d;
> ErrorCode rv;
>
> rv = BigNum_Initialize(&a); if(rv != ERROR_SUCCESS) goto
> fail0;
> rv = BigNum_Initialize(&b); if(rv != ERROR_SUCCESS) goto
> fail1;
> rv = BigNum_Initialize(&c); if(rv != ERROR_SUCCESS) goto
> fail2;
> rv = BigNum_Initialize(&d); if(rv != ERROR_SUCCESS) goto
> fail3;
>
> /* do some math */
> rv = BigNum_Set(&b, 3); if(rv != ERROR_SUCCESS) goto fail4;
>
> ...
>
> /* free buffers */
> rv = BigNum_Free(&d); if(rv != ERROR_SUCCESS) goto fail3;
> rv = BigNum_Free(&c); if(rv != ERROR_SUCCESS) goto fail2;
> rv = BigNum_Free(&b); if(rv != ERROR_SUCCESS) goto fail1;
> rv = BigNum_Free(&a); if(rv != ERROR_SUCCESS) goto fail0;
>
> return(ERROR_SUCCESS);
>
> fail4: BigNum_Free(&d);
> fail3: BigNum_Free(&c);
> fail2: BigNum_Free(&b);
> fail1: BigNum_Free(&a);
> fail0: return(rv);
> }
> ---
>
> But we've violated Djikstra and we've used a "bad" goto. How would
> _you_ write MyFunc() above?
Your question is really about style. As is usually the case in
such matters, there are no right or wrong answers, just individual
preference, and perhaps local culture that should also be taken
into account.
That said, when a question like this comes up, usually it's a
strong indication that the program design is wrong at some
higher level. If you find yourself writing lots of ugly
functions, there's a good chance it will be worth rethinking
some higher-level decisions and see if a different approach
leads to cleaner code at the function level.
[toc] | [prev] | [next] | [standalone]
| From | mike3 <mike4ty4@yahoo.com> |
|---|---|
| Date | 2012-05-31 13:49 -0700 |
| Message-ID | <58595afa-412f-4ef0-b66e-bbad70698a2d@s6g2000pbi.googlegroups.com> |
| In reply to | #21596 |
On May 31, 2:19 pm, Tim Rentsch <t...@alumni.caltech.edu> wrote:
> mike3 <mike4...@yahoo.com> writes:
> > I've got some stuff that looks like this:
>
> > ---
> > ErrorCode MyFunc()
> > {
> > BigNum a, b, c, d;
> > ErrorCode rv;
>
> > rv = BigNum_Initialize(&a);
> > if(rv != ERROR_SUCCESS)
> > return(rv);
>
> > rv = BigNum_Initialize(&b);
> > if(rv != ERROR_SUCCESS)
> > {
> > BigNum_Free(&a); /* and what if THIS fails??? :) */
> > return(rv);
> > }
>
> > rv = BigNum_Initialize(&c);
> > if(rv != ERROR_SUCCESS)
> > {
> > BigNum_Free(&b);
> > BigNum_Free(&a);
> > return(rv);
> > }
>
> > rv = BigNum_Initialize(&d);
> > if(rv != ERROR_SUCCESS)
> > {
> > BigNum_Free(&c);
> > BigNum_Free(&b);
> > BigNum_Free(&a);
> > return(rv);
> > }
>
> > /* do some math */
> > rv = BigNum_Set(&b, 3);
> > if(rv != ERROR_SUCCESS)
> > {
> > BigNum_Free(&d);
> > BigNum_Free(&c);
> > BigNum_Free(&b);
> > BigNum_Free(&a);
> > return(rv);
> > }
>
> > ...
>
> > /* free buffers */
> > rv = BigNum_Free(&d);
> > if(rv != ERROR_SUCCESS)
> > {
> > BigNum_Free(&c);
> > BigNum_Free(&b);
> > BigNum_Free(&a);
> > return(rv);
> > }
>
> > rv = BigNum_Free(&c);
> > if(rv != ERROR_SUCCESS)
> > {
> > BigNum_Free(&b);
> > BigNum_Free(&a);
> > return(rv);
> > }
>
> > rv = BigNum_Free(&b);
> > if(rv != ERROR_SUCCESS)
> > {
> > BigNum_Free(&a);
> > return(rv);
> > }
>
> > rv = BigNum_Free(&a);
> > if(rv != ERROR_SUCCESS)
> > return(rv);
>
> > return(ERROR_SUCCESS);
> > }
> > ---
>
> > But this is nasty, with all those duplicated "free" blocks. What can
> > be done to relieve this code duplication? It's ugly, it hurts my
> > freaking eyes and my nose is screaming for relief. And it hurts
> > maintainability to no end -- what if we decide to add more capability
> > to MyFunc() that requires additional bignums? Oy... We'd have to
> > update _all those blocks_.
>
> > I was thinking about using a "goto", but Gotos are Bad, aren't they? I
> > can't believe I may have to use a goto! What about Djikstra's famous
> > letter? Is it possible that perhaps a goto may be GOOD here? Because
> > with a goto this would all seem much simpler. If we violate Djikstra,
> > we get:
>
> > ---
>
> > ErrorCode MyFunc()
> > {
> > BigNum a, b, c, d;
> > ErrorCode rv;
>
> > rv = BigNum_Initialize(&a); if(rv != ERROR_SUCCESS) goto
> > fail0;
> > rv = BigNum_Initialize(&b); if(rv != ERROR_SUCCESS) goto
> > fail1;
> > rv = BigNum_Initialize(&c); if(rv != ERROR_SUCCESS) goto
> > fail2;
> > rv = BigNum_Initialize(&d); if(rv != ERROR_SUCCESS) goto
> > fail3;
>
> > /* do some math */
> > rv = BigNum_Set(&b, 3); if(rv != ERROR_SUCCESS) goto fail4;
>
> > ...
>
> > /* free buffers */
> > rv = BigNum_Free(&d); if(rv != ERROR_SUCCESS) goto fail3;
> > rv = BigNum_Free(&c); if(rv != ERROR_SUCCESS) goto fail2;
> > rv = BigNum_Free(&b); if(rv != ERROR_SUCCESS) goto fail1;
> > rv = BigNum_Free(&a); if(rv != ERROR_SUCCESS) goto fail0;
>
> > return(ERROR_SUCCESS);
>
> > fail4: BigNum_Free(&d);
> > fail3: BigNum_Free(&c);
> > fail2: BigNum_Free(&b);
> > fail1: BigNum_Free(&a);
> > fail0: return(rv);
> > }
> > ---
>
> > But we've violated Djikstra and we've used a "bad" goto. How would
> > _you_ write MyFunc() above?
>
> Your question is really about style. As is usually the case in
> such matters, there are no right or wrong answers, just individual
> preference, and perhaps local culture that should also be taken
> into account.
>
> That said, when a question like this comes up, usually it's a
> strong indication that the program design is wrong at some
> higher level. If you find yourself writing lots of ugly
> functions, there's a good chance it will be worth rethinking
> some higher-level decisions and see if a different approach
> leads to cleaner code at the function level.
So what would the "bad design" be in this case? There doesn't
seem to be a whole lot of things that could be changed. A bignum
system will have init, free, and arithmetic routines. Trouble
seems to be due to the possibility of return codes on every
bignum operation. Is this the "design problem"? Notice that
something like, say, GMP, doesn't do that. All GMP functions
return void or an arithmetic result, not an error code. But I *do*
want to have some sort of error reporting functionality.
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-05-31 22:08 +0100 |
| Message-ID | <jq8mjr$mlg$1@dont-email.me> |
| In reply to | #21597 |
"mike3" <mike4ty4@yahoo.com> wrote in message news:58595afa-412f-4ef0-b66e-bbad70698a2d@s6g2000pbi.googlegroups.com... > On May 31, 2:19 pm, Tim Rentsch <t...@alumni.caltech.edu> wrote: >> That said, when a question like this comes up, usually it's a >> strong indication that the program design is wrong at some >> higher level. If you find yourself writing lots of ugly >> functions, there's a good chance it will be worth rethinking >> some higher-level decisions and see if a different approach >> leads to cleaner code at the function level. > > So what would the "bad design" be in this case? There doesn't > seem to be a whole lot of things that could be changed. A bignum > system will have init, free, and arithmetic routines. Trouble > seems to be due to the possibility of return codes on every > bignum operation. Is this the "design problem"? Sounds like it. But whatever you end up doing, perhaps consider the possibility of having a second set of functions that shadow the main ones (and which could wrap the main functions). These secondary functions take care of error-checking. Then the programmer can do more productive work without worrying about errors 90% of the time. Of course it depends on what sort of errors are likely; if they are rare, and an abort (or one of those longjmps) is acceptable when there is a problem, then this can be workable. But it is also up to the programmer which set of functions to call. It depends also how the code that uses this library fits into the overall program; if this is just servicing something bigger, such as a language runtime, then you don't want minor numeric problems to bring down the system. In any case, ignoring checking an errorcode shouldn't bring down the system either; but this could need *more* checking inside the library itself (which you may or may not have access to). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | mike3 <mike4ty4@yahoo.com> |
|---|---|
| Date | 2012-05-31 16:08 -0700 |
| Message-ID | <f1087dec-3a3e-4037-9f6b-8740e5f59094@pr7g2000pbb.googlegroups.com> |
| In reply to | #21600 |
On May 31, 3:08 pm, "BartC" <b...@freeuk.com> wrote: > "mike3" <mike4...@yahoo.com> wrote in message > > news:58595afa-412f-4ef0-b66e-bbad70698a2d@s6g2000pbi.googlegroups.com... > > > On May 31, 2:19 pm, Tim Rentsch <t...@alumni.caltech.edu> wrote: > >> That said, when a question like this comes up, usually it's a > >> strong indication that the program design is wrong at some > >> higher level. If you find yourself writing lots of ugly > >> functions, there's a good chance it will be worth rethinking > >> some higher-level decisions and see if a different approach > >> leads to cleaner code at the function level. > > > So what would the "bad design" be in this case? There doesn't > > seem to be a whole lot of things that could be changed. A bignum > > system will have init, free, and arithmetic routines. Trouble > > seems to be due to the possibility of return codes on every > > bignum operation. Is this the "design problem"? > > Sounds like it. > > But whatever you end up doing, perhaps consider the possibility of having a > second set of functions that shadow the main ones (and which could wrap the > main functions). > > These secondary functions take care of error-checking. Then the programmer > can do more productive work without worrying about errors 90% of the time. > > Of course it depends on what sort of errors are likely; if they are rare, > and an abort (or one of those longjmps) is acceptable when there is a > problem, then this can be workable. But it is also up to the programmer > which set of functions to call. > > It depends also how the code that uses this library fits into the overall > program; if this is just servicing something bigger, such as a language > runtime, then you don't want minor numeric problems to bring down the > system. > > In any case, ignoring checking an errorcode shouldn't bring down the system > either; but this could need *more* checking inside the library itself (which > you may or may not have access to). > > -- > Bartc However, some of these errors can't simply be ignored, like an "out of memory" error or "out of disk space" error. And it would also be a nice feature to know if something has gone wrong with the computation.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2012-05-31 17:34 -0700 |
| Message-ID | <kfn4nqvzx7t.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #21597 |
mike3 <mike4ty4@yahoo.com> writes: > On May 31, 2:19 pm, Tim Rentsch <t...@alumni.caltech.edu> wrote: >> mike3 <mike4...@yahoo.com> writes: >> [snip] >> >> Your question is really about style. As is usually the case in >> such matters, there are no right or wrong answers, just individual >> preference, and perhaps local culture that should also be taken >> into account. >> >> That said, when a question like this comes up, usually it's a >> strong indication that the program design is wrong at some >> higher level. If you find yourself writing lots of ugly >> functions, there's a good chance it will be worth rethinking >> some higher-level decisions and see if a different approach >> leads to cleaner code at the function level. > > So what would the "bad design" be in this case? To answer that question one would need both more specific information and more context. The example you gave was fairly limited and also rather abstract. Not saying there is anything wrong with that, there isn't, but it doesn't provide enough information to answer the followup question. > There doesn't seem to be a whole lot of things that could be > changed. [snip elaboration] Undoubtedly there are lots of things that can't be changed, but unless the situation is very different from what I would expect there still are lots of design choices available. Maybe you have locked in on some unconscious assumptions? I'm sorry I don't have a better answer for you, but the question you're asking now is much larger than the original topic.
[toc] | [prev] | [next] | [standalone]
| From | Willem <willem@toad.stack.nl> |
|---|---|
| Date | 2012-06-01 07:40 +0000 |
| Message-ID | <slrnjsgsfl.317k.willem@toad.stack.nl> |
| In reply to | #21597 |
mike3 wrote:
) So what would the "bad design" be in this case? There doesn't
) seem to be a whole lot of things that could be changed. A bignum
) system will have init, free, and arithmetic routines. Trouble
) seems to be due to the possibility of return codes on every
) bignum operation. Is this the "design problem"? Notice that
) something like, say, GMP, doesn't do that. All GMP functions
) return void or an arithmetic result, not an error code. But I *do*
) want to have some sort of error reporting functionality.
A better design would be to catch errors into the bignum type itself,
and propagate that through the calculations. I.E.: Have 'error' be
a possible value for a bignum (or perhaps multiple 'error' values)
and whenever an 'error' value is used in a calculation, the result
is also (that same) 'error'.
That way, you can calculate away without error handling and at the
end do one single error check to see if everything went well.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
[toc] | [prev] | [next] | [standalone]
| From | mike3 <mike4ty4@yahoo.com> |
|---|---|
| Date | 2012-05-31 16:39 -0700 |
| Subject | GOTOs discovered in "real world" program! (was Re: Error returns and repeated code, GOTOs, etc.) |
| Message-ID | <d4477aa8-f837-4bee-bb40-fbcc3da179c0@pr7g2000pbb.googlegroups.com> |
| In reply to | #21522 |
On May 29, 11:44 pm, mike3 <mike4...@yahoo.com> wrote:
<snip>
I've made an interesting and disturbing discovery.
I found THIS:
http://www.isc.org/software/bind/991
I decided to have a look at the source code, and oh my goodness! What
did I find?!
Oh NO....!!!!!!!!!!!!!!!!!!!!!!! :
----
idn_result_t
idn_normalizer_add(idn_normalizer_t ctx, const char *scheme_name) {
idn_result_t r;
void *v;
normalize_scheme_t *scheme;
assert(ctx != NULL && scheme_name != NULL);
TRACE(("idn_normalizer_add(scheme_name=%s)\n", scheme_name));
assert(INITIALIZED);
if (idn__strhash_get(scheme_hash, scheme_name, &v) != idn_success) {
ERROR(("idn_normalizer_add(): invalid scheme \"%-.30s\"\n",
scheme_name));
r = idn_invalid_name;
goto ret;
<----------------- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
}
scheme = v;
assert(ctx->nschemes <= ctx->scheme_size);
if (ctx->nschemes == ctx->scheme_size &&
(r = expand_schemes(ctx)) != idn_success) {
goto ret;
<----------------- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
}
ctx->schemes[ctx->nschemes++] = scheme;
r = idn_success;
ret:
<----------------- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
TRACE(("idn_normalizer_add(): %s\n", idn_result_tostring(r)));
return (r);
}
----
YES, that's right -- those are GOTOs in there, and they do this a LOT
in this program! Djikstra!!!
But as this thread seems to show, it looks like that there exist
alternatives
to GOTO, and so we can still uphold Djikstra's law. Or is there
something
about this program that makes it OK to use GOTOs in it, but it is not
OK
to use them in the one I'm doing?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-06-01 03:21 +0100 |
| Subject | Re: GOTOs discovered in "real world" program! |
| Message-ID | <0.c0b748eb6e2be6ebe731.20120601032112BST.871ulzhiw7.fsf@bsb.me.uk> |
| In reply to | #21611 |
mike3 <mike4ty4@yahoo.com> writes:
> On May 29, 11:44 pm, mike3 <mike4...@yahoo.com> wrote:
> <snip>
>
> I've made an interesting and disturbing discovery.
>
> I found THIS:
>
> http://www.isc.org/software/bind/991
>
> I decided to have a look at the source code, and oh my goodness! What
> did I find?!
> Oh NO....!!!!!!!!!!!!!!!!!!!!!!! :
>
> ----
>
> idn_result_t
> idn_normalizer_add(idn_normalizer_t ctx, const char *scheme_name) {
> idn_result_t r;
> void *v;
> normalize_scheme_t *scheme;
>
> assert(ctx != NULL && scheme_name != NULL);
>
> TRACE(("idn_normalizer_add(scheme_name=%s)\n", scheme_name));
>
> assert(INITIALIZED);
>
> if (idn__strhash_get(scheme_hash, scheme_name, &v) != idn_success) {
> ERROR(("idn_normalizer_add(): invalid scheme \"%-.30s\"\n",
> scheme_name));
> r = idn_invalid_name;
> goto ret;
> <----------------- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> }
>
> scheme = v;
>
> assert(ctx->nschemes <= ctx->scheme_size);
>
> if (ctx->nschemes == ctx->scheme_size &&
> (r = expand_schemes(ctx)) != idn_success) {
> goto ret;
> <----------------- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> }
>
> ctx->schemes[ctx->nschemes++] = scheme;
> r = idn_success;
> ret:
> <----------------- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> TRACE(("idn_normalizer_add(): %s\n", idn_result_tostring(r)));
> return (r);
> }
>
> ----
>
> YES, that's right -- those are GOTOs in there, and they do this a LOT
> in this program! Djikstra!!!
It's Dijkstra, OK? Dijkstra.
The above is a terrible example. It looks like programming by numbers:
"I've been told to trace entry and exit so I'll stick a label at the end
and replace returns with gotos". I think it's clearer without them,
although there is some justification if my guess is right -- it might
have been a ploy to minimise re-writing.
> But as this thread seems to show, it looks like that there exist
> alternatives to GOTO, and so we can still uphold Djikstra's law.
It's not a law. The famous article is a well-argued case. Do read it
if you haven't.
> Or is there something about this program that makes it OK to use GOTOs
> in it, but it is not OK to use them in the one I'm doing?
I don't know the program, but this function does not benefit from having
gotos. There are cases where a goto really helps, but they are far
fewer than some people think.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | mike3 <mike4ty4@yahoo.com> |
|---|---|
| Date | 2012-06-01 03:49 -0700 |
| Subject | Re: GOTOs discovered in "real world" program! |
| Message-ID | <2f24e278-3b37-4c71-bcda-0693d139997b@oo8g2000pbc.googlegroups.com> |
| In reply to | #21616 |
On May 31, 8:21 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote: > mike3 <mike4...@yahoo.com> writes: > > YES, that's right -- those are GOTOs in there, and they do this a LOT > > in this program! Djikstra!!! > > It's Dijkstra, OK? Dijkstra. > OK... > The above is a terrible example. It looks like programming by numbers: > "I've been told to trace entry and exit so I'll stick a label at the end > and replace returns with gotos". I think it's clearer without them, > although there is some justification if my guess is right -- it might > have been a ploy to minimise re-writing. > To me, it looks like they're trying to reuse the TRACE call. So that one could modify the TRACE call without having to modify a clone at another point in the routine. Would it be OK to duplicate the line at each return point? > > But as this thread seems to show, it looks like that there exist > > alternatives to GOTO, and so we can still uphold Djikstra's law. > > It's not a law. The famous article is a well-argued case. Do read it > if you haven't. > > > Or is there something about this program that makes it OK to use GOTOs > > in it, but it is not OK to use them in the one I'm doing? > > I don't know the program, but this function does not benefit from having > gotos. There are cases where a goto really helps, but they are far > fewer than some people think. > Mmmm. So how would you write those returns?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-06-02 02:15 +0100 |
| Subject | Re: GOTOs discovered in "real world" program! |
| Message-ID | <0.75e4dbc98085c35ddc67.20120602021532BST.87mx4mfr9n.fsf@bsb.me.uk> |
| In reply to | #21627 |
mike3 <mike4ty4@yahoo.com> writes:
> On May 31, 8:21 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> mike3 <mike4...@yahoo.com> writes:
>> > YES, that's right -- those are GOTOs in there, and they do this a LOT
>> > in this program! Djikstra!!!
<snip>
>> The above is a terrible example. It looks like programming by numbers:
>> "I've been told to trace entry and exit so I'll stick a label at the end
>> and replace returns with gotos". I think it's clearer without them,
>> although there is some justification if my guess is right -- it might
>> have been a ploy to minimise re-writing.
>
> To me, it looks like they're trying to reuse the TRACE call.
Yes, but what came first? If the tracing was there originally and the
logic of the function was subsequently made more complex, doing it with
gotos makes no sense to me. If the logic was there and used multiple
returns when the tracing was added, I can see some value in making the
minimum of changes -- just replace the returns with jumps.
> So that
> one could modify the TRACE call without having to modify a clone at
> another point in the routine. Would it be OK to duplicate the line at
> each return point?
No, of course not.
<snip>
>> I don't know the program, but this function does not benefit from having
>> gotos. There are cases where a goto really helps, but they are far
>> fewer than some people think.
>
> Mmmm. So how would you write those returns?
Having got this far -- a single return -- I would add any more. I'd
just write the function using natural structures rather than jumps:
idn_result_t
idn_normalizer_add(idn_normalizer_t ctx, const char *scheme_name) {
idn_result_t r;
void *v;
assert(ctx != NULL && scheme_name != NULL);
TRACE(("idn_normalizer_add(scheme_name=%s)\n", scheme_name));
assert(INITIALIZED);
if (idn__strhash_get(scheme_hash, scheme_name, &v) != idn_success) {
ERROR(("idn_normalizer_add(): invalid scheme \"%-.30s\"\n",
scheme_name));
r = idn_invalid_name;
}
else {
assert(ctx->nschemes <= ctx->scheme_size);
if (ctx->nschemes != ctx->scheme_size ||
(r = expand_schemes(ctx)) == idn_success) {
ctx->schemes[ctx->nschemes++] = v;
r = idn_success;
}
}
TRACE(("idn_normalizer_add(): %s\n", idn_result_tostring(r)));
return r;
}
(I've also removed an unneeded variable: "scheme", but it would probably
be better to rename "v" as "scheme" now.)
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | mike3 <mike4ty4@yahoo.com> |
|---|---|
| Date | 2012-06-01 19:45 -0700 |
| Subject | Re: GOTOs discovered in "real world" program! |
| Message-ID | <e1a74e58-e5b4-4939-837f-8df2384f1855@st3g2000pbc.googlegroups.com> |
| In reply to | #21641 |
On Jun 1, 7:15 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> mike3 <mike4...@yahoo.com> writes:
<snip>
> > To me, it looks like they're trying to reuse the TRACE call.
>
> Yes, but what came first? If the tracing was there originally and the
> logic of the function was subsequently made more complex, doing it with
> gotos makes no sense to me. If the logic was there and used multiple
> returns when the tracing was added, I can see some value in making the
> minimum of changes -- just replace the returns with jumps.
>
You mean a goto?
<snip>
> > Mmmm. So how would you write those returns?
>
> Having got this far -- a single return -- I would add any more. I'd
> just write the function using natural structures rather than jumps:
>
> idn_result_t
> idn_normalizer_add(idn_normalizer_t ctx, const char *scheme_name) {
> idn_result_t r;
> void *v;
>
> assert(ctx != NULL && scheme_name != NULL);
> TRACE(("idn_normalizer_add(scheme_name=%s)\n", scheme_name));
> assert(INITIALIZED);
>
> if (idn__strhash_get(scheme_hash, scheme_name, &v) != idn_success) {
> ERROR(("idn_normalizer_add(): invalid scheme \"%-.30s\"\n",
> scheme_name));
> r = idn_invalid_name;
> }
> else {
> assert(ctx->nschemes <= ctx->scheme_size);
>
> if (ctx->nschemes != ctx->scheme_size ||
> (r = expand_schemes(ctx)) == idn_success) {
> ctx->schemes[ctx->nschemes++] = v;
> r = idn_success;
> }
> }
> TRACE(("idn_normalizer_add(): %s\n", idn_result_tostring(r)));
> return r;
> }
>
> (I've also removed an unneeded variable: "scheme", but it would probably
> be better to rename "v" as "scheme" now.)
>
Hmm. This looks like the "nest" approach suggested on this thread by
Ike Naar. I suppose it'd be OK in this case, since there are only a
couple of
error-code-returning calls and so the nesting does not get too deep.
But
what if you had like 5 calls or more (and with something that's not a
bignum
package, so you couldn't, e.g. pass error codes inside bignums)?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-06-02 15:00 +0100 |
| Subject | Re: GOTOs discovered in "real world" program! |
| Message-ID | <0.46d3cef8a9c1f6e6b7c4.20120602150113BST.87hauterti.fsf@bsb.me.uk> |
| In reply to | #21642 |
mike3 <mike4ty4@yahoo.com> writes:
> On Jun 1, 7:15 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> mike3 <mike4...@yahoo.com> writes:
> <snip>
>> > To me, it looks like they're trying to reuse the TRACE call.
>>
>> Yes, but what came first? If the tracing was there originally and the
>> logic of the function was subsequently made more complex, doing it with
>> gotos makes no sense to me. If the logic was there and used multiple
>> returns when the tracing was added, I can see some value in making the
>> minimum of changes -- just replace the returns with jumps.
>
> You mean a goto?
Yes.
> <snip>
>> > Mmmm. So how would you write those returns?
>>
>> Having got this far -- a single return -- I would add any more. I'd
>> just write the function using natural structures rather than jumps:
>>
>> idn_result_t
>> idn_normalizer_add(idn_normalizer_t ctx, const char *scheme_name) {
>> idn_result_t r;
>> void *v;
>>
>> assert(ctx != NULL && scheme_name != NULL);
>> TRACE(("idn_normalizer_add(scheme_name=%s)\n", scheme_name));
>> assert(INITIALIZED);
>>
>> if (idn__strhash_get(scheme_hash, scheme_name, &v) != idn_success) {
>> ERROR(("idn_normalizer_add(): invalid scheme \"%-.30s\"\n",
>> scheme_name));
>> r = idn_invalid_name;
>> }
>> else {
>> assert(ctx->nschemes <= ctx->scheme_size);
>>
>> if (ctx->nschemes != ctx->scheme_size ||
>> (r = expand_schemes(ctx)) == idn_success) {
>> ctx->schemes[ctx->nschemes++] = v;
>> r = idn_success;
>> }
>> }
>> TRACE(("idn_normalizer_add(): %s\n", idn_result_tostring(r)));
>> return r;
>> }
>>
>> (I've also removed an unneeded variable: "scheme", but it would probably
>> be better to rename "v" as "scheme" now.)
>>
>
> Hmm. This looks like the "nest" approach suggested on this thread by
> Ike Naar. I suppose it'd be OK in this case, since there are only a
> couple of error-code-returning calls and so the nesting does not get
> too deep. But what if you had like 5 calls or more (and with
> something that's not a bignum package, so you couldn't, e.g. pass
> error codes inside bignums)?
Give an example, and I'll comment. I can't see exactly what it is you
are saying. I presume it is not just the code that you originally
posted, since I commented on that.
Having, multiple early error cases does not always lead to conceptually
deep nesting. If you have:
if (C1) {
rc = E1;
goto error;
}
if (C2) {
rc = E2;
goto error;
}
if (C3) {
rc = E3;
goto error;
}
/* main error-free code */
error:
/* common clean-up code */
return rc;
you can turn it into:
if (C1)
rc = E1;
else if (C2)
rc = E2;
else if (C3)
rc = E3;
else {
/* main error-free code */
}
/* common clean-up code */
return rc;
That's deeply nested in the most literal sense, but no one would have
any trouble reasoning about the nesting, eleven if were 100 levels deep.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | mike3 <mike4ty4@yahoo.com> |
|---|---|
| Date | 2012-06-02 16:44 -0700 |
| Subject | Re: GOTOs discovered in "real world" program! |
| Message-ID | <0c2a9c04-382f-4e5d-9eff-891070d76ccd@oo8g2000pbc.googlegroups.com> |
| In reply to | #21681 |
On Jun 2, 8:00 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> mike3 <mike4...@yahoo.com> writes:
<snip>
> > You mean a goto?
>
> Yes.
>
Thanks for the explanation.
<snip>
> > Hmm. This looks like the "nest" approach suggested on this thread by
> > Ike Naar. I suppose it'd be OK in this case, since there are only a
> > couple of error-code-returning calls and so the nesting does not get
> > too deep. But what if you had like 5 calls or more (and with
> > something that's not a bignum package, so you couldn't, e.g. pass
> > error codes inside bignums)?
>
> Give an example, and I'll comment. I can't see exactly what it is you
> are saying. I presume it is not just the code that you originally
> posted, since I commented on that.
>
> Having, multiple early error cases does not always lead to conceptually
> deep nesting. If you have:
>
> if (C1) {
> rc = E1;
> goto error;
> }
> if (C2) {
> rc = E2;
> goto error;
> }
> if (C3) {
> rc = E3;
> goto error;
> }
> /* main error-free code */
> error:
> /* common clean-up code */
> return rc;
>
> you can turn it into:
>
> if (C1)
> rc = E1;
> else if (C2)
> rc = E2;
> else if (C3)
> rc = E3;
> else {
> /* main error-free code */
> }
> /* common clean-up code */
> return rc;
>
> That's deeply nested in the most literal sense, but no one would have
> any trouble reasoning about the nesting, eleven if were 100 levels deep.
>
So you're suggesting to abuse the if() to create a list of executed
functions
that breaks off at an error, then, right? Is that a "dirty" trick?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-06-03 03:51 +0100 |
| Subject | Re: GOTOs discovered in "real world" program! |
| Message-ID | <0.76fb886f33c556e43adf.20120603035129BST.874nqtds5q.fsf@bsb.me.uk> |
| In reply to | #21729 |
mike3 <mike4ty4@yahoo.com> writes:
> On Jun 2, 8:00 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> mike3 <mike4...@yahoo.com> writes:
> <snip>
>> > You mean a goto?
>>
>> Yes.
>>
>
> Thanks for the explanation.
>
> <snip>
>> > Hmm. This looks like the "nest" approach suggested on this thread by
>> > Ike Naar. I suppose it'd be OK in this case, since there are only a
>> > couple of error-code-returning calls and so the nesting does not get
>> > too deep. But what if you had like 5 calls or more (and with
>> > something that's not a bignum package, so you couldn't, e.g. pass
>> > error codes inside bignums)?
>>
>> Give an example, and I'll comment. I can't see exactly what it is you
>> are saying. I presume it is not just the code that you originally
>> posted, since I commented on that.
>>
>> Having, multiple early error cases does not always lead to conceptually
>> deep nesting. If you have:
>>
>> if (C1) {
>> rc = E1;
>> goto error;
>> }
>> if (C2) {
>> rc = E2;
>> goto error;
>> }
>> if (C3) {
>> rc = E3;
>> goto error;
>> }
>> /* main error-free code */
>> error:
>> /* common clean-up code */
>> return rc;
>>
>> you can turn it into:
>>
>> if (C1)
>> rc = E1;
>> else if (C2)
>> rc = E2;
>> else if (C3)
>> rc = E3;
>> else {
>> /* main error-free code */
>> }
>> /* common clean-up code */
>> return rc;
>>
>> That's deeply nested in the most literal sense, but no one would have
>> any trouble reasoning about the nesting, eleven if were 100 levels deep.
>
> So you're suggesting to abuse the if() to create a list of executed
> functions
> that breaks off at an error, then, right? Is that a "dirty" trick?
I can't made head or tail of that. If you consider my use of if .. else
if ... to be an abuse, I doubt we have enough common ground debate this
point, but that seems like an unlikely position to hold and does not
explain the "list of executed functions" remark.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Aaron W. Hsu" <arcfide@sacrideo.us> |
|---|---|
| Date | 2012-06-01 12:06 -0400 |
| Subject | Re: GOTOs discovered in "real world" program! |
| Message-ID | <NridnVhRHsQUdVXSnZ2dnUVZ_vGdnZ2d@giganews.com> |
| In reply to | #21616 |
Ben Bacarisse wrote: >> But as this thread seems to show, it looks like that there exist >> alternatives to GOTO, and so we can still uphold Djikstra's law. > > It's not a law. The famous article is a well-argued case. Do read it > if you haven't. Knuth has a famous "retort" to the GOTO article. Donald E. Knuth. 1974. Structured Programming with go to Statements. ACM Comput. Surv. 6, 4 (December 1974), 261-301. DOI=10.1145/356635.356640 http://doi.acm.org/10.1145/356635.356640 -- Aaron W. Hsu | arcfide@sacrideo.us | http://www.sacrideo.us Programming is just another word for the lost art of thinking.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-06-02 02:01 +0100 |
| Subject | Re: GOTOs discovered in "real world" program! |
| Message-ID | <0.63b2d8368cd5e409cc76.20120602020110BST.87vcjafrxl.fsf@bsb.me.uk> |
| In reply to | #21629 |
"Aaron W. Hsu" <arcfide@sacrideo.us> writes: > Ben Bacarisse wrote: > >>> But as this thread seems to show, it looks like that there exist >>> alternatives to GOTO, and so we can still uphold Djikstra's law. >> >> It's not a law. The famous article is a well-argued case. Do read it >> if you haven't. > > Knuth has a famous "retort" to the GOTO article. I am sure you know (hence the quotes) that it is not a refutation of what Dijkstra wrote. Knuth says: I argue for the elimination of go to's in certain cases, and for their introduction in others. I believe that by presenting such a view I am not in fact disagreeing sharply with Dijkstra's ideas, since he recently wrote the following: "Please don't fall into the trap of believing that I am terribly dogmatical about [the go to statement]." Both are models of clarity, and neither is dogmatic. I feel sure that if all gotos in all programs had been as well-reasoned for as those in Knuth's paper, Dijkstra would never have written his. > Donald E. Knuth. 1974. Structured Programming with go to Statements. ACM > Comput. Surv. 6, 4 (December 1974), 261-301. DOI=10.1145/356635.356640 > http://doi.acm.org/10.1145/356635.356640 -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | mike3 <mike4ty4@yahoo.com> |
|---|---|
| Date | 2012-06-01 19:46 -0700 |
| Subject | Re: GOTOs discovered in "real world" program! |
| Message-ID | <7a4b0b8b-0834-4d0e-a97a-f8ff3d188bca@qz1g2000pbc.googlegroups.com> |
| In reply to | #21640 |
On Jun 1, 7:01 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote: > "Aaron W. Hsu" <arcf...@sacrideo.us> writes: <snip> > Both are models of clarity, and neither is dogmatic. I feel sure that > if all gotos in all programs had been as well-reasoned for as those in > Knuth's paper, Dijkstra would never have written his. > But I take it that, from what I've seen on this thread, using gotos to jump to error code handlers is _not_ a "well-reasoned" use, right, and so Djikstra's rules still apply?
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web