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

Is goto Still Considered Harmful?

Started by	Lynn McGuire <lmc@winsim.com>
First post	2014-03-12 11:02 -0500
Last post	2014-03-29 05:56 -0700
Articles	20 on this page of 149 — 45 participants

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

  Is goto Still Considered Harmful? Lynn McGuire <lmc@winsim.com> - 2014-03-12 11:02 -0500
    Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-12 12:17 -0400
    Re: Is goto Still Considered Harmful? nospam@see.signature (Richard Maine) - 2014-03-12 09:20 -0700
      Re: Is goto Still Considered Harmful? Lynn McGuire <lmc@winsim.com> - 2014-03-18 16:30 -0500
        Re: Is goto Still Considered Harmful? Geoff <geoff@invalid.invalid> - 2014-03-18 17:36 -0700
          Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-19 07:34 -0400
            Re: Is goto Still Considered Harmful? "BartC" <bc@freeuk.com> - 2014-03-19 12:08 +0000
              Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-19 10:07 -0400
                Re: Is goto Still Considered Harmful? Richard <rgrdev_@gmail.com> - 2014-03-19 17:05 +0100
              Re: Is goto Still Considered Harmful? Lynn McGuire <lmc@winsim.com> - 2014-03-19 12:27 -0500
        Re: Is goto Still Considered Harmful? "Terence" <tbwright@bigpond.net.au> - 2014-03-19 20:35 +1100
          Re: Is goto Still Considered Harmful? Lynn McGuire <lmc@winsim.com> - 2014-03-19 12:26 -0500
    Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-12 16:47 +0000
      Re: Is goto Still Considered Harmful? Jos Bergervoet <jos.bergervoet@xs4all.nl> - 2014-03-12 19:07 +0100
        Re: Is goto Still Considered Harmful? Andrew Cooper <root@127.0.0.1> - 2014-03-12 23:36 +0000
          Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-13 00:23 +0000
            Re: Is goto Still Considered Harmful? Andrew Cooper <root@127.0.0.1> - 2014-03-13 01:18 +0000
              Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-13 02:08 +0000
                Re: Is goto Still Considered Harmful? Andrew Cooper <root@127.0.0.1> - 2014-03-13 02:21 +0000
                Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-13 11:17 +0100
          Re: Is goto Still Considered Harmful? Melzzzzz <mel@zzzzz.invalid> - 2014-03-13 01:53 +0100
        Re: Is goto Still Considered Harmful? Les Cargill <lcargill99@comcast.com> - 2014-03-13 01:46 -0500
      Re: Is goto Still Considered Harmful? Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-03-13 10:56 +0100
      Re: Is goto Still Considered Harmful? "Nasser M. Abbasi" <nma@12000.org> - 2014-03-16 08:18 -0500
        Re: Is goto Still Considered Harmful? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-03-16 15:18 +0000
          Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-20 11:36 -0700
    Re: Is goto Still Considered Harmful? "BartC" <bc@freeuk.com> - 2014-03-12 18:50 +0000
      Re: Is goto Still Considered Harmful? <william@wilbur.25thandClement.com> - 2014-03-12 12:49 -0700
      Re: Is goto Still Considered Harmful? "Qolin" <noone@nowhere.com> - 2014-03-12 21:54 +0000
        Re: Is goto Still Considered Harmful? Lynn McGuire <lmc@winsim.com> - 2014-03-12 16:57 -0500
        Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-12 15:36 -0700
          Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-12 19:02 -0400
            Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-12 16:58 -0700
              Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-12 20:09 -0400
          Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-12 16:44 -0700
        Re: Is goto Still Considered Harmful? Robert Wessel <robertwessel2@yahoo.com> - 2014-03-12 23:40 -0500
          Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-13 11:25 +0100
          Re: Is goto Still Considered Harmful? Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2014-03-14 11:24 +0100
            Re: Is goto Still Considered Harmful? Robert Wessel <robertwessel2@yahoo.com> - 2014-03-14 23:32 -0500
            Re: Is goto Still Considered Harmful? Dr Nick <nospam-4@temporary-address.org.uk> - 2014-03-15 13:43 +0000
              Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-15 16:28 +0100
                Re: Is goto Still Considered Harmful? Dr Nick <nospam-4@temporary-address.org.uk> - 2014-03-15 16:01 +0000
                  Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-17 08:51 +0100
      Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-13 11:22 +0100
    Re: Is goto Still Considered Harmful? ralph <nt_consulting@yahoo.com> - 2014-03-12 15:34 -0500
    Re: Is goto Still Considered Harmful? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2014-03-12 17:48 -0700
    Re: Is goto Still Considered Harmful? jt@toerring.de (Jens Thoms Toerring) - 2014-03-13 01:06 +0000
      Re: Is goto Still Considered Harmful? wilson <winslole@udayton.edu> - 2014-03-13 03:59 -0400
        Re: Is goto Still Considered Harmful? wilson <winslole@udayton.edu> - 2014-03-13 05:02 -0400
          Re: Is goto Still Considered Harmful? Richard Damon <Richard@Damon-Family.org> - 2014-03-13 08:42 -0400
            Re: Is goto Still Considered Harmful? gazelle@shell.xmission.com (Kenny McCormack) - 2014-03-13 14:45 +0000
      Re: Is goto Still Considered Harmful? Louis Krupp <lkrupp@nospam.pssw.com.invalid> - 2014-03-13 07:42 -0600
        Re: Is goto Still Considered Harmful? Richard <rgrdev_@gmail.com> - 2014-03-13 14:56 +0100
    Re: Is goto Still Considered Harmful? Wolfgang Kilian <kilian@invalid.com> - 2014-03-13 09:10 +0100
    Re: Is goto Still Considered Harmful? mark.bluemel@gmail.com - 2014-03-13 08:02 -0700
    Re: Is goto Still Considered Harmful? Thomas Koenig <tkoenig@netcologne.de> - 2014-03-13 21:09 +0000
      Re: Is goto Still Considered Harmful? "Qolin" <noone@nowhere.com> - 2014-03-13 21:24 +0000
        Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-13 22:36 +0000
          Re: Is goto Still Considered Harmful? Robert Wessel <robertwessel2@yahoo.com> - 2014-03-13 23:02 -0500
            Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-14 04:07 +0000
              Re: Is goto Still Considered Harmful? Robert Wessel <robertwessel2@yahoo.com> - 2014-03-13 23:56 -0500
            Re: Is goto Still Considered Harmful? helbig@astro.multiCLOTHESvax.de (Phillip Helbig---undress to reply) - 2014-03-14 09:17 +0000
      Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-13 22:42 +0000
        Re: Is goto Still Considered Harmful? "James Van Buskirk" <not_valid@comcast.net> - 2014-03-13 17:13 -0600
          Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-13 16:46 -0700
            Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-14 01:17 +0000
              Re: Is goto Still Considered Harmful? Robert Wessel <robertwessel2@yahoo.com> - 2014-03-13 23:04 -0500
                Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-14 10:41 +0100
                  Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-14 09:55 +0000
                    Re: Is goto Still Considered Harmful? David Brown <david.brown@hesbynett.no> - 2014-03-14 13:16 +0100
                    Re: Is goto Still Considered Harmful? Seebs <usenet-nospam@seebs.net> - 2014-03-18 21:08 +0000
                      Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-18 17:41 -0400
          Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-14 00:45 +0000
            Re: Is goto Still Considered Harmful? "James Van Buskirk" <not_valid@comcast.net> - 2014-03-13 21:40 -0600
              Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-14 01:02 -0400
                Re: Is goto Still Considered Harmful? "James Van Buskirk" <not_valid@comcast.net> - 2014-03-14 10:36 -0600
                  Re: Is goto Still Considered Harmful? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-03-14 17:30 +0000
                  Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-14 13:51 -0400
                    Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-14 13:12 -0700
                  Re: Is goto Still Considered Harmful? Tim Rentsch <txr@alumni.caltech.edu> - 2014-03-29 06:46 -0700
              Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-14 05:29 +0000
                Re: Is goto Still Considered Harmful? "James Van Buskirk" <not_valid@comcast.net> - 2014-03-14 10:47 -0600
                  Re: Is goto Still Considered Harmful? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-03-14 17:43 +0000
                  Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-14 13:52 -0400
              Re: Is goto Still Considered Harmful? Stephen Sprunk <stephen@sprunk.org> - 2014-03-16 17:15 -0500
                Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-16 16:04 -0700
      Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-14 05:11 +0000
        Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-14 06:00 +0000
    Re: Is goto Still Considered Harmful? "Terence" <tbwright@bigpond.net.au> - 2014-03-14 08:32 +1100
      Re: Is goto Still Considered Harmful? Richard Damon <Richard@Damon-Family.org> - 2014-03-14 23:10 -0400
    Re: Is goto Still Considered Harmful? Rosario193 <Rosario@invalid.invalid> - 2014-03-14 02:18 +0100
      Re: Is goto Still Considered Harmful? Lynn McGuire <lmc@winsim.com> - 2014-03-18 16:14 -0500
    Re: Is goto Still Considered Harmful? John Bode <jfbode1029@gmail.com> - 2014-03-24 07:52 -0700
      Re: Is goto Still Considered Harmful? Ken Brody <kenbrody@spamcop.net> - 2014-03-24 11:20 -0400
        Re: Is goto Still Considered Harmful? "BartC" <bc@freeuk.com> - 2014-03-24 17:08 +0000
        Re: Is goto Still Considered Harmful? Ken Brody <kenbrody@spamcop.net> - 2014-03-25 14:06 -0400
          Re: Is goto Still Considered Harmful? Lowell Gilbert <lgusenet@be-well.ilk.org> - 2014-03-26 13:31 -0400
      Re: Is goto Still Considered Harmful? gazelle@shell.xmission.com (Kenny McCormack) - 2014-03-24 16:31 +0000
      Re: Is goto Still Considered Harmful? "BartC" <bc@freeuk.com> - 2014-03-24 16:46 +0000
        Re: Is goto Still Considered Harmful? John Bode <jfbode1029@gmail.com> - 2014-03-24 16:10 -0700
          Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-24 17:19 -0700
            Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-25 02:56 -0700
            Re: Is goto Still Considered Harmful? Keith Thompson <kst-u@mib.org> - 2014-03-25 07:34 -0700
              Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-25 10:57 -0400
                Re: Is goto Still Considered Harmful? gazelle@shell.xmission.com (Kenny McCormack) - 2014-03-25 16:09 +0000
                Re: Is goto Still Considered Harmful? Kaz Kylheku <kaz@kylheku.com> - 2014-03-25 16:14 +0000
                  Re: Is goto Still Considered Harmful? Ian Collins <ian-news@hotmail.com> - 2014-03-26 08:06 +1300
                  Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-25 12:49 -0700
                  Re: Is goto Still Considered Harmful? Stephen Sprunk <stephen@sprunk.org> - 2014-03-31 14:05 -0500
                    Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-31 15:20 -0400
                      Re: Is goto Still Considered Harmful? Stephen Sprunk <stephen@sprunk.org> - 2014-04-04 14:56 -0500
                        Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-04-04 17:11 -0400
                          Re: Is goto Still Considered Harmful? Ian Collins <ian-news@hotmail.com> - 2014-04-05 12:03 +1300
                          Re: Is goto Still Considered Harmful? ralph <nt_consulting@yahoo.com> - 2014-04-05 00:17 -0500
                            Re: Is goto Still Considered Harmful? Ian Collins <ian-news@hotmail.com> - 2014-04-05 20:14 +1300
                          Re: Is goto Still Considered Harmful? Stephen Sprunk <stephen@sprunk.org> - 2014-04-09 14:30 -0500
                            Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-04-09 16:37 -0400
                              Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-09 14:01 -0700
                        Re: Is goto Still Considered Harmful? Richard <rgrdev_@gmail.com> - 2014-04-05 15:21 +0100
                    Re: Is goto Still Considered Harmful? Ian Collins <ian-news@hotmail.com> - 2014-04-01 11:04 +1300
                      Re: Is goto Still Considered Harmful? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2014-04-01 02:45 +0300
                        Re: Is goto Still Considered Harmful? Ian Collins <ian-news@hotmail.com> - 2014-04-01 13:03 +1300
                          Re: Is goto Still Considered Harmful? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2014-05-22 12:01 +0300
                            Re: Is goto Still Considered Harmful? Ian Collins <ian-news@hotmail.com> - 2014-05-22 21:22 +1200
                        Re: Is goto Still Considered Harmful? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2014-05-22 11:53 +0300
                Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-31 12:10 -0400
                  Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-31 10:39 -0700
                    Re: Is goto Still Considered Harmful? Stephen Sprunk <stephen@sprunk.org> - 2014-03-31 13:42 -0500
                      Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-31 15:16 -0700
                        Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-01 00:24 -0700
                          Re: Is goto Still Considered Harmful? Richard Damon <Richard@Damon-Family.org> - 2014-04-01 08:26 -0400
                            Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-01 06:50 -0700
                              Re: Are setters Stil Considered Harmful? (was: Is goto Still Considered Harmful?) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-02 10:49 -0700
              Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-25 19:30 +0000
                Re: Is goto Still Considered Harmful? Ken Brody <kenbrody@spamcop.net> - 2014-03-27 09:33 -0400
              Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-25 19:37 +0000
          Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-25 00:30 -0400
          Re: Is goto Still Considered Harmful? John Bode <jfbode1029@gmail.com> - 2014-03-27 11:47 -0700
            Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-27 20:39 -0400
              Re: Is goto Still Considered Harmful? gazelle@shell.xmission.com (Kenny McCormack) - 2014-03-28 01:40 +0000
            Re: Is goto Still Considered Harmful? Richard <rgrdev_@gmail.com> - 2014-03-28 10:09 +0100
              Re: Is goto Still Considered Harmful? gazelle@shell.xmission.com (Kenny McCormack) - 2014-03-28 09:48 +0000
              Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-28 03:24 -0700
                Re: Is goto Still Considered Harmful? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-28 18:52 +0000
                Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-30 02:45 -0700
      Re: Is goto Still Considered Harmful? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-24 12:53 -0700
      Re: Is goto Still Considered Harmful? John Bode <jfbode1029@gmail.com> - 2014-03-24 15:02 -0700
        Re: Is goto Still Considered Harmful? James Kuyper <jameskuyper@verizon.net> - 2014-03-24 19:11 -0400
    Re: Is goto Still Considered Harmful? Tim Rentsch <txr@alumni.caltech.edu> - 2014-03-29 05:56 -0700

Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →

#41872

From	David Brown <david.brown@hesbynett.no>
Date	2014-03-15 16:28 +0100
Message-ID	<lg1ril$4h9$1@dont-email.me>
In reply to	#41870

On 15/03/14 14:43, Dr Nick wrote:
> Thomas Jahns <jahns@idontlikespam.dkrz.de> writes:
> 
>> On 03/13/14 05:40, Robert Wessel wrote:
>>> What really puzzles me about this bug is that pretty much all C/C++
>>> compilers for large systems (and certainly GCC), will issue an
>>> "unreachable code" warning at all but the minimal warning level.  At
>>> least around here the policy is compile at a high warning level, and
>>> treat warnings as errors, not doing something like that, especially in
>>> security critical code, just seems sloppy.
>>
>> http://gcc.gnu.org/ml/gcc-help/2011-05/msg00360.html
> 
> That's completely bonkers!  Of course it will give different warnings on
> different optimisation settings.  But so what?  No-one is asking it to
> warn about /all/ unreachable code (that's solving the halting problem).
> But warning about some of it is better than warning about none.  Surely!

I believe the problem is that when you optimise, a lot of code can be
eliminated.  For example, if you have this:

#define startX 10
#define stopX 20

static inline int abs(int x) {
	if (x < 0) {
		return -x;
	} else {
		return x;
	}
}

void foo(void) {
	for (int x = startX, x < stopX, x++) {
		printf("%d: %d\n", x, abs(x));
	}
}

When gcc used to have the "-Wunreachable-code" warning, this would give
a warning on the "return -x" line when optimising - because that line
/is/ unreachable in this code.  But such a warning is extremely
unhelpful here - it is not uncommon to write code that will not actually
be executed because you write your functions in general terms.

Without being privy to the gcc maintainers' thoughts at the time (I
haven't read the mailing lists), I expect it was very difficult to find
a way to distinguish between such intentional unreachable code, and
unintentional unreachable code.  Note that even the duplicate "goto
fail" line could occur as intentional code as a result of pre-processing
and macros (especially combined with the poor bracketing style of the
code's authors).

I am always a fan of more warnings, and I would have preferred it to
remain an option (but not in -Wall) - perhaps it was not practical to
maintain it with useful enough results.

> 
>> so gcc won't warn. Apple uses clang, there the option is not part of -Wall and
>> therefore easily missed. I'd also advocate using it, because it very often
>> indicates a block of code improperly compiled (e.g. because of missing #ifdef's).
> 
> Well quite.
>

[toc] | [prev] | [next] | [standalone]

#41876

From	Dr Nick <nospam-4@temporary-address.org.uk>
Date	2014-03-15 16:01 +0000
Message-ID	<87mwgrv4b0.fsf@temporary-address.org.uk>
In reply to	#41872

David Brown <david.brown@hesbynett.no> writes:

> On 15/03/14 14:43, Dr Nick wrote:
>> Thomas Jahns <jahns@idontlikespam.dkrz.de> writes:
>> 
>>> On 03/13/14 05:40, Robert Wessel wrote:
>>>> What really puzzles me about this bug is that pretty much all C/C++
>>>> compilers for large systems (and certainly GCC), will issue an
>>>> "unreachable code" warning at all but the minimal warning level.  At
>>>> least around here the policy is compile at a high warning level, and
>>>> treat warnings as errors, not doing something like that, especially in
>>>> security critical code, just seems sloppy.
>>>
>>> http://gcc.gnu.org/ml/gcc-help/2011-05/msg00360.html
>> 
>> That's completely bonkers!  Of course it will give different warnings on
>> different optimisation settings.  But so what?  No-one is asking it to
>> warn about /all/ unreachable code (that's solving the halting problem).
>> But warning about some of it is better than warning about none.  Surely!
>
>
> I believe the problem is that when you optimise, a lot of code can be
> eliminated.  For example, if you have this:
>
> #define startX 10
> #define stopX 20
>
> static inline int abs(int x) {
> 	if (x < 0) {
> 		return -x;
> 	} else {
> 		return x;
> 	}
> }
>
> void foo(void) {
> 	for (int x = startX, x < stopX, x++) {
> 		printf("%d: %d\n", x, abs(x));
> 	}
> }
>
>
> When gcc used to have the "-Wunreachable-code" warning, this would give
> a warning on the "return -x" line when optimising - because that line
> /is/ unreachable in this code.  But such a warning is extremely
> unhelpful here - it is not uncommon to write code that will not actually
> be executed because you write your functions in general terms.

Ah yes, I do see what you mean.  As you say, a general purpose function
that's being used in a very constrained set of circumstances.

OTOH, it is warning you that you are doing a pointless abs call, but in
a fairly indirect way.

> Without being privy to the gcc maintainers' thoughts at the time (I
> haven't read the mailing lists), I expect it was very difficult to find
> a way to distinguish between such intentional unreachable code, and
> unintentional unreachable code.  Note that even the duplicate "goto
> fail" line could occur as intentional code as a result of pre-processing
> and macros (especially combined with the poor bracketing style of the
> code's authors).
>
> I am always a fan of more warnings, and I would have preferred it to
> remain an option (but not in -Wall) - perhaps it was not practical to
> maintain it with useful enough results.

Yes, I may have been a bit premature, thanks!

[toc] | [prev] | [next] | [standalone]

#41912

From	David Brown <david.brown@hesbynett.no>
Date	2014-03-17 08:51 +0100
Message-ID	<lg69hs$3qi$1@dont-email.me>
In reply to	#41876

On 15/03/14 17:01, Dr Nick wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
>> On 15/03/14 14:43, Dr Nick wrote:
>>> Thomas Jahns <jahns@idontlikespam.dkrz.de> writes:
>>>
>>>> On 03/13/14 05:40, Robert Wessel wrote:
>>>>> What really puzzles me about this bug is that pretty much all C/C++
>>>>> compilers for large systems (and certainly GCC), will issue an
>>>>> "unreachable code" warning at all but the minimal warning level.  At
>>>>> least around here the policy is compile at a high warning level, and
>>>>> treat warnings as errors, not doing something like that, especially in
>>>>> security critical code, just seems sloppy.
>>>>
>>>> http://gcc.gnu.org/ml/gcc-help/2011-05/msg00360.html
>>>
>>> That's completely bonkers!  Of course it will give different warnings on
>>> different optimisation settings.  But so what?  No-one is asking it to
>>> warn about /all/ unreachable code (that's solving the halting problem).
>>> But warning about some of it is better than warning about none.  Surely!
>>
>>
>> I believe the problem is that when you optimise, a lot of code can be
>> eliminated.  For example, if you have this:
>>
>> #define startX 10
>> #define stopX 20
>>
>> static inline int abs(int x) {
>> 	if (x < 0) {
>> 		return -x;
>> 	} else {
>> 		return x;
>> 	}
>> }
>>
>> void foo(void) {
>> 	for (int x = startX, x < stopX, x++) {
>> 		printf("%d: %d\n", x, abs(x));
>> 	}
>> }
>>
>>
>> When gcc used to have the "-Wunreachable-code" warning, this would give
>> a warning on the "return -x" line when optimising - because that line
>> /is/ unreachable in this code.  But such a warning is extremely
>> unhelpful here - it is not uncommon to write code that will not actually
>> be executed because you write your functions in general terms.
> 
> Ah yes, I do see what you mean.  As you say, a general purpose function
> that's being used in a very constrained set of circumstances.
> 
> OTOH, it is warning you that you are doing a pointless abs call, but in
> a fairly indirect way.
> 
>> Without being privy to the gcc maintainers' thoughts at the time (I
>> haven't read the mailing lists), I expect it was very difficult to find
>> a way to distinguish between such intentional unreachable code, and
>> unintentional unreachable code.  Note that even the duplicate "goto
>> fail" line could occur as intentional code as a result of pre-processing
>> and macros (especially combined with the poor bracketing style of the
>> code's authors).
>>
>> I am always a fan of more warnings, and I would have preferred it to
>> remain an option (but not in -Wall) - perhaps it was not practical to
>> maintain it with useful enough results.
> 
> Yes, I may have been a bit premature, thanks!
> 

The world of C and C compilers is full of subtle issues like this.
Whenever you think "they must have been mad to do that", there is
probably some reason you are missing!

[toc] | [prev] | [next] | [standalone]

#41731

From	David Brown <david.brown@hesbynett.no>
Date	2014-03-13 11:22 +0100
Message-ID	<lfs0sp$as9$1@dont-email.me>
In reply to	#41675

On 12/03/14 19:50, BartC wrote:
> 
> 
> "Lynn McGuire" <lmc@winsim.com> wrote in message
> news:lfq0fp$4dp$1@dont-email.me...
>> Is goto Still Considered Harmful?
>>
>> http://www.drdobbs.com/architecture-and-design/is-goto-still-considered-harmful/240166595
>>
> 
> Yes it is frowned upon and it is bad practice. But I'd prefer that a
> language still has it just in case (many don't; C does, otherwise I
> wouldn't
> be here - I need it for auto-generated code).
> 
> But the code error in the article was about how code blocks are delimited:
> 
> if (a)
>   b;
>   c;
> if (d) ...
> 
> Statements b and c are both indented and look at first glance as though
> they
> belong to the preceding if-condition, but c (which happened to be a goto)
> was always executed.
> 
> Insisting that all statement sequences have {...} braces, even when
> there is
> only one statement, I think would have helped. (Also having statements
> require a matching closing delimiter, but C uses {...} braces for
> everything.)
> 
> As it is, it is common for a statement such as c to not have a } to close
> it, so it's easier to miss the bug.
> 

That was my first thought too.  I stick to two forms of conditional:

if (a) b;

and

if (a) {
    b;
}

I only use the first form if "b" is simple, there is no "else", and
there are no doubts that it is a single statement.  Examples are simple
assignment, return statements, and (though I seldom use them) goto's.
Otherwise I insist on brackets.

[toc] | [prev] | [next] | [standalone]

#41684

From	ralph <nt_consulting@yahoo.com>
Date	2014-03-12 15:34 -0500
Message-ID	<8rf1i9tn94ob4tp0929mfu6c5votqgl26s@4ax.com>
In reply to	#41668

On Wed, 12 Mar 2014 11:02:56 -0500, Lynn McGuire <lmc@winsim.com>
wrote:

>Is goto Still Considered Harmful?
> 
>http://www.drdobbs.com/architecture-and-design/is-goto-still-considered-harmful/240166595
>

Take a look at the following article for a more complete examination
of the goto, and Dijkstra opinion of them.
http://c2.com/cgi/wiki?GotoConsideredHarmful

Note the context within Dijkstra wrote his original comment.
Programming languages have changed a bit since then*, but the general
premise remains.

1) Gotos are useful when they are part of confined, consistent, and
obvious control constructs.
2) Gotos are not useful when they result in Spaghetti Code or provide
opportunity for surprises.

I especially liked the observation:
"... since exceptions are a type of GOTO, precisely the same reasoning
applies to them: most of the places they could be used for non-error
processing, they should not be".

-ralph
[*deliberately understated. <g>]

[toc] | [prev] | [next] | [standalone]

#41707

From	"Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date	2014-03-12 17:48 -0700
Message-ID	<e17fe516-63c7-488d-a7ec-1f6ccbd0cc4b@googlegroups.com>
In reply to	#41668

On Wednesday, March 12, 2014 12:02:56 PM UTC-4, Lynn McGuire wrote:
> Is goto Still Considered Harmful?
> 
> http://www.drdobbs.com/architecture-and-design/is-goto-still-considered-harmful/240166595
> 
> Lynn


Troll. :-)

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#41710

From	jt@toerring.de (Jens Thoms Toerring)
Date	2014-03-13 01:06 +0000
Message-ID	<bocekjFts3fU1@mid.uni-berlin.de>
In reply to	#41668

In comp.lang.c Lynn McGuire <lmc@winsim.com> wrote:
> Is goto Still Considered Harmful?
>  
> http://www.drdobbs.com/architecture-and-design/is-goto-still-considered-harmful/240166595

First of all, this actually's no issue restricted to a GOTO.
Everytime you do sometking like

  if ( some_condition )
      do_A( );
      do_B( );

there's an obvious problem (at least if this has been written
under the assumption that do_B() would only be invoked in case
that 'some_condition' is true) - how bad the results are depends
on what the do_B() call does.

In some cases it might help to religiously enclose IF blocks in
curly braces to make such problems stand out more. E.g.

  if ( some_condition ) {
      do_A( );
  }
      do_B( );

may be more visible (but that always requires that someone is
actually looking at this code and starts wondering what's going
on).

The "Pythonistats" had their day, claiming that it never would
have happened to them due to to the relevance of white-space in
Python. I'm not convinced, I think it could have happened even
more easily in Python (given they had a GOTO statement) since
an editor can't even know when to indent.

With a reasonable editor (or a indentation tool) this flaw
could easily have been exposed to anyone taking jist a super-
ficial glance, i.e., if some rather easy to understand code
like this (after proper indentation)

  if ( some_condition )
      goto fail;
  goto fail;
  if ( some_other_condition )
      goto fail;

doesn't raise an alarm bell what ever will? And the whole layout
of the code isn't very convincing:

  if ((err = SSLFreeBuffer(&hashCtx)) != 0)
      goto fail;
  if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0)
      goto fail;
  if ((err = SSLHashSHA1.update(&hashCtx &clientRandom)) != 0)
      goto fail;
      goto fail;

Why not make it more easy to read like e.g. 

  if (    ( err = SSLFreeBuffer(      &hashCtx               ) )
       || ( err = ReadyHash(          &SSLHashSHA1, &hashCtx ) )
       || ( err = SSLHashSHA1.update( &hashCtx &clientRandom ) ) )
      goto fail;

(I'd also put a comment in front of that, trying to expalin
what that's supposed to check.)

The only thing I can see here is another example of "don't
repeat yourself" - if you have to write "goto fail;" many
times in a row something is fishy, someone just mechani-
cally copy-and-past-ed without giving it a thought...

I guess the only way to avoid such things is to indent code cor-
rectly (using all tools available) and looking out for anything
that doesn't look right on first sight.

And when it comes to Dykstra's "Goto considered harmful" this
seems to be really far-fetched. The paper is from 1968 (nearly
50 yeares ago) and times and programming practices were quite
different back then (quite before my time;-). While I'd comple-
tely agree that something like (and I guess that's something
akin to what Dykstra actually was ranting about)

  GOTO i 237, 384, 293, 204, 381, 493, 1002, 536, 785, 662

- as could and would be done in FORTRAN (I've seen code like
this and was unlucky enough to have to try to unravel it) - is
definitely "harmful", but that's nothing anybody in a sane
state of mind would do in a modern computer language (unless
for an obfuscation contest). But that bears no relationship to
some simple and straightforward GOTOs in otherwise sane code.

                           Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#41719

From	wilson <winslole@udayton.edu>
Date	2014-03-13 03:59 -0400
Message-ID	<op.xcnhtzn01hq4pq@leon-hp>
In reply to	#41710

On Wed, 12 Mar 2014 21:06:29 -0400, Jens Thoms Toerring <jt@toerring.de>  
wrote:

> In comp.lang.c Lynn McGuire <lmc@winsim.com> wrote:
>> Is goto Still Considered Harmful?
>>
>> http://www.drdobbs.com/architecture-and-design/is-goto-still-considered-harmful/240166595
>
> First of all, this actually's no issue restricted to a GOTO.
> Everytime you do sometking like
>
>   if ( some_condition )
>       do_A( );
>       do_B( );
>
> there's an obvious problem (at least if this has been written
> under the assumption that do_B() would only be invoked in case
> that 'some_condition' is true) - how bad the results are depends
> on what the do_B() call does.
>
> In some cases it might help to religiously enclose IF blocks in
> curly braces to make such problems stand out more. E.g.
>
>   if ( some_condition ) {
>       do_A( );
>   }
>       do_B( );
>
> may be more visible (but that always requires that someone is
> actually looking at this code and starts wondering what's going
> on).
>
> The "Pythonistats" had their day, claiming that it never would
> have happened to them due to to the relevance of white-space in
> Python. I'm not convinced, I think it could have happened even
> more easily in Python (given they had a GOTO statement) since
> an editor can't even know when to indent.
>
> With a reasonable editor (or a indentation tool) this flaw
> could easily have been exposed to anyone taking jist a super-
> ficial glance, i.e., if some rather easy to understand code
> like this (after proper indentation)
>
>   if ( some_condition )
>       goto fail;
>   goto fail;
>   if ( some_other_condition )
>       goto fail;
>
> doesn't raise an alarm bell what ever will? And the whole layout
> of the code isn't very convincing:
>
>   if ((err = SSLFreeBuffer(&hashCtx)) != 0)
>       goto fail;
>   if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0)
>       goto fail;
>   if ((err = SSLHashSHA1.update(&hashCtx &clientRandom)) != 0)
>       goto fail;
>       goto fail;
>
> Why not make it more easy to read like e.g.
>
>   if (    ( err = SSLFreeBuffer(      &hashCtx               ) )
>        || ( err = ReadyHash(          &SSLHashSHA1, &hashCtx ) )
>        || ( err = SSLHashSHA1.update( &hashCtx &clientRandom ) ) )
>       goto fail;
>
> (I'd also put a comment in front of that, trying to expalin
> what that's supposed to check.)
>
> The only thing I can see here is another example of "don't
> repeat yourself" - if you have to write "goto fail;" many
> times in a row something is fishy, someone just mechani-
> cally copy-and-past-ed without giving it a thought...
>
> I guess the only way to avoid such things is to indent code cor-
> rectly (using all tools available) and looking out for anything
> that doesn't look right on first sight.
>
> And when it comes to Dykstra's "Goto considered harmful" this
> seems to be really far-fetched. The paper is from 1968 (nearly
> 50 yeares ago) and times and programming practices were quite
> different back then (quite before my time;-). While I'd comple-
> tely agree that something like (and I guess that's something
> akin to what Dykstra actually was ranting about)
>
>   GOTO i 237, 384, 293, 204, 381, 493, 1002, 536, 785, 662
>
> - as could and would be done in FORTRAN (I've seen code like
> this and was unlucky enough to have to try to unravel it) - is
> definitely "harmful", but that's nothing anybody in a sane
> state of mind would do in a modern computer language (unless
> for an obfuscation contest). But that bears no relationship to
> some simple and straightforward GOTOs in otherwise sane code.
>
>                            Regards, Jens


My two cents for whatever it is worth.

Of all the suggestions, I like this use of logical "or"s  the best.

It makes it clear exactly what is happening.
And with a compileer that exits the checking of the Boolean as soon as if  
finds a negative value (almost all compilers today) it is as fast as the  
original version.
The result: clarity and speed.
-- 

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

[toc] | [prev] | [next] | [standalone]

#41721

From	wilson <winslole@udayton.edu>
Date	2014-03-13 05:02 -0400
Message-ID	<op.xcnkquu31hq4pq@leon-hp>
In reply to	#41719

On Thu, 13 Mar 2014 03:59:49 -0400, wilson <winslole@udayton.edu> wrote:

> On Wed, 12 Mar 2014 21:06:29 -0400, Jens Thoms Toerring <jt@toerring.de>  
> wrote:
>
>> In comp.lang.c Lynn McGuire <lmc@winsim.com> wrote:
>>> Is goto Still Considered Harmful?
>>>
>>> http://www.drdobbs.com/architecture-and-design/is-goto-still-considered-harmful/240166595
>>
>> First of all, this actually's no issue restricted to a GOTO.
>> Everytime you do sometking like
>>
>>   if ( some_condition )
>>       do_A( );
>>       do_B( );
>>
>> there's an obvious problem (at least if this has been written
>> under the assumption that do_B() would only be invoked in case
>> that 'some_condition' is true) - how bad the results are depends
>> on what the do_B() call does.
>>
>> In some cases it might help to religiously enclose IF blocks in
>> curly braces to make such problems stand out more. E.g.
>>
>>   if ( some_condition ) {
>>       do_A( );
>>   }
>>       do_B( );
>>
>> may be more visible (but that always requires that someone is
>> actually looking at this code and starts wondering what's going
>> on).
>>
>> The "Pythonistats" had their day, claiming that it never would
>> have happened to them due to to the relevance of white-space in
>> Python. I'm not convinced, I think it could have happened even
>> more easily in Python (given they had a GOTO statement) since
>> an editor can't even know when to indent.
>>
>> With a reasonable editor (or a indentation tool) this flaw
>> could easily have been exposed to anyone taking jist a super-
>> ficial glance, i.e., if some rather easy to understand code
>> like this (after proper indentation)
>>
>>   if ( some_condition )
>>       goto fail;
>>   goto fail;
>>   if ( some_other_condition )
>>       goto fail;
>>
>> doesn't raise an alarm bell what ever will? And the whole layout
>> of the code isn't very convincing:
>>
>>   if ((err = SSLFreeBuffer(&hashCtx)) != 0)
>>       goto fail;
>>   if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0)
>>       goto fail;
>>   if ((err = SSLHashSHA1.update(&hashCtx &clientRandom)) != 0)
>>       goto fail;
>>       goto fail;
>>
>> Why not make it more easy to read like e.g.
>>
>>   if (    ( err = SSLFreeBuffer(      &hashCtx               ) )
>>        || ( err = ReadyHash(          &SSLHashSHA1, &hashCtx ) )
>>        || ( err = SSLHashSHA1.update( &hashCtx &clientRandom ) ) )
>>       goto fail;
>>
>> (I'd also put a comment in front of that, trying to expalin
>> what that's supposed to check.)
>>
>> The only thing I can see here is another example of "don't
>> repeat yourself" - if you have to write "goto fail;" many
>> times in a row something is fishy, someone just mechani-
>> cally copy-and-past-ed without giving it a thought...
>>
>> I guess the only way to avoid such things is to indent code cor-
>> rectly (using all tools available) and looking out for anything
>> that doesn't look right on first sight.
>>
>> And when it comes to Dykstra's "Goto considered harmful" this
>> seems to be really far-fetched. The paper is from 1968 (nearly
>> 50 yeares ago) and times and programming practices were quite
>> different back then (quite before my time;-). While I'd comple-
>> tely agree that something like (and I guess that's something
>> akin to what Dykstra actually was ranting about)
>>
>>   GOTO i 237, 384, 293, 204, 381, 493, 1002, 536, 785, 662
>>
>> - as could and would be done in FORTRAN (I've seen code like
>> this and was unlucky enough to have to try to unravel it) - is
>> definitely "harmful", but that's nothing anybody in a sane
>> state of mind would do in a modern computer language (unless
>> for an obfuscation contest). But that bears no relationship to
>> some simple and straightforward GOTOs in otherwise sane code.
>>
>>                            Regards, Jens
>
>
> My two cents for whatever it is worth.
>
> Of all the suggestions, I like this use of logical "or"s  the best.
>
> It makes it clear exactly what is happening.
> And with a compileer that exits the checking of the Boolean as soon as  
> if finds a negative value (almost all compilers today) it is as fast as  
> the original version.
> The result: clarity and speed.


Sorry.  That last lines hould have read the program exits checking the  
Boolean as soon as it finds a true condition.  A false consditon sends it  
on to check the next conditon.  Again, almost all current cvompilelrs skip  
checking the rest of the Boolean as soon as possible.

My only excuse is that it is late at night.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

[toc] | [prev] | [next] | [standalone]

#41741

From	Richard Damon <Richard@Damon-Family.org>
Date	2014-03-13 08:42 -0400
Message-ID	<2JhUu.178734$hV.139325@en-nntp-16.dc1.easynews.com>
In reply to	#41721

On 3/13/14, 5:02 AM, wilson wrote:
> On Thu, 13 Mar 2014 03:59:49 -0400, wilson <winslole@udayton.edu> wrote:
>
>> My two cents for whatever it is worth.
>>
>> Of all the suggestions, I like this use of logical "or"s  the best.
>>
>> It makes it clear exactly what is happening.
>> And with a compileer that exits the checking of the Boolean as soon as
>> if finds a negative value (almost all compilers today) it is as fast
>> as the original version.
>> The result: clarity and speed.
> 
> 
> Sorry.  That last lines hould have read the program exits checking the
> Boolean as soon as it finds a true condition.  A false consditon sends
> it on to check the next conditon.  Again, almost all current cvompilelrs
> skip checking the rest of the Boolean as soon as possible.
> 
> My only excuse is that it is late at night.
> 

One would hope that ALL compilers make || and && a short-circuit
evaluation as it is REQUIRED to be by the standard, and has been since K&R.

[toc] | [prev] | [next] | [standalone]

#41753

From	gazelle@shell.xmission.com (Kenny McCormack)
Date	2014-03-13 14:45 +0000
Message-ID	<lfsgao$3u1$1@news.xmission.com>
In reply to	#41741

In article <2JhUu.178734$hV.139325@en-nntp-16.dc1.easynews.com>,
Richard Damon  <Richard@Damon-Family.org> wrote:
...
>> Sorry.  That last lines hould have read the program exits checking the
>> Boolean as soon as it finds a true condition.  A false consditon sends
>> it on to check the next conditon.  Again, almost all current cvompilelrs
>> skip checking the rest of the Boolean as soon as possible.

>One would hope that ALL compilers make || and && a short-circuit
>evaluation as it is REQUIRED to be by the standard, and has been since K&R.

Indeed.  One wonders two things:

    1) Why the previous poster thought that the functionality was optional.
	(And that "almost all" compilers do it this way)

    2) Why roving gangs of regs haven't pounced on this already.

P.S.  There is exactly one language that I know of, that uses && and ||, for
"and" and "or", respectively, that doesn't implement the so-called "short
circuit" evaluation.  That language is "WinBatch" (www.winbatch.com).

-- 
Just for a change of pace, this sig is *not* an obscure reference to
comp.lang.c...

[toc] | [prev] | [next] | [standalone]

#41745

From	Louis Krupp <lkrupp@nospam.pssw.com.invalid>
Date	2014-03-13 07:42 -0600
Message-ID	<rvc3i99fhvn87h92537vv0bkfd7rlmj54n@4ax.com>
In reply to	#41710

On 13 Mar 2014 01:06:29 GMT, jt@toerring.de (Jens Thoms Toerring)
wrote:

<snip>

>And the whole layout
>of the code isn't very convincing:
>
>  if ((err = SSLFreeBuffer(&hashCtx)) != 0)
>      goto fail;
>  if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0)
>      goto fail;
>  if ((err = SSLHashSHA1.update(&hashCtx &clientRandom)) != 0)
>      goto fail;

<snip>

>Why not make it more easy to read like e.g. 
>
>  if (    ( err = SSLFreeBuffer(      &hashCtx               ) )
>       || ( err = ReadyHash(          &SSLHashSHA1, &hashCtx ) )
>       || ( err = SSLHashSHA1.update( &hashCtx &clientRandom ) ) )
>      goto fail;

The latter is easier to read, but the former, with each function call
in a separate statement on a different line, is likely to be easier to
step through with a debugger.  When the code takes the error branch,
you know with a bit more confidence which function returned an error.

Louis

[toc] | [prev] | [next] | [standalone]

#41747

From	Richard <rgrdev_@gmail.com>
Date	2014-03-13 14:56 +0100
Message-ID	<87lhwejj7v.fsf@gmail.com>
In reply to	#41745

Louis Krupp <lkrupp@nospam.pssw.com.invalid> writes:

> On 13 Mar 2014 01:06:29 GMT, jt@toerring.de (Jens Thoms Toerring)
> wrote:
>
> <snip>
>
>>And the whole layout
>>of the code isn't very convincing:
>>
>>  if ((err = SSLFreeBuffer(&hashCtx)) != 0)
>>      goto fail;
>>  if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0)
>>      goto fail;
>>  if ((err = SSLHashSHA1.update(&hashCtx &clientRandom)) != 0)
>>      goto fail;
>
> <snip>
>
>>Why not make it more easy to read like e.g. 
>>
>>  if (    ( err = SSLFreeBuffer(      &hashCtx               ) )
>>       || ( err = ReadyHash(          &SSLHashSHA1, &hashCtx ) )
>>       || ( err = SSLHashSHA1.update( &hashCtx &clientRandom ) ) )
>>      goto fail;
>
> The latter is easier to read, but the former, with each function call
> in a separate statement on a different line, is likely to be easier to
> step through with a debugger.  When the code takes the error branch,
> you know with a bit more confidence which function returned an error.

If you have to use a debugger your code is already broken according to
the regs here who have never ever had to use one. Debugging is ten times
harder than making the code correct the first time apparently .....

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

[toc] | [prev] | [next] | [standalone]

#41720

From	Wolfgang Kilian <kilian@invalid.com>
Date	2014-03-13 09:10 +0100
Message-ID	<lfrp6b$pmd$1@dont-email.me>
In reply to	#41668

On 03/12/2014 05:02 PM, Lynn McGuire wrote:
> Is goto Still Considered Harmful?
>
> http://www.drdobbs.com/architecture-and-design/is-goto-still-considered-harmful/240166595
>
>
> Lynn

Nobody mentioned exception handling, yet?

If goto is useful in a language, it is a sign that the language is 
lacking exceptions as a concept.  Error conditions and breaking out of a 
loop are covered by

try ... raise EXC ... catch EXC ...

or similar, if the language supports it.  While the control flow is the 
same, it expresses the intention of the programmer.  Also, it doesn't 
permit control flow to accidentally reach the 'catch' part, which is 
another common error.

(Exceptions have an issue with properly cleaning up, but that is the 
same with explicit goto.)

-- Wolfgang

-- 
E-mail: firstnameinitial.lastname@domain.de
Domain: yahoo

[toc] | [prev] | [next] | [standalone]

#41755

From	mark.bluemel@gmail.com
Date	2014-03-13 08:02 -0700
Message-ID	<f1fddbb6-6b16-424e-9bdc-d444b6c6e59a@googlegroups.com>
In reply to	#41668

On Wednesday, 12 March 2014 16:02:56 UTC, Lynn McGuire  wrote:
> Is goto Still Considered Harmful?

In my hands, yes. Mind you, I'm also at risk with kitchen knives.

My first programming job was using COBOL-68. In-house standards led to label 
names like "C-100", "CA-100", "CAA-100", "CB-100" and so on. It was all to easy 
to branch to the wrong one, so I stopped using GOTO and wrote GOTO-less code in 
COBOL for about 7 years.

I currently mainly code in Java which has no "goto", and don't feel the lack.

When coding in C, I would consider using goto for error exits, perhaps, but otherwise try to avoid them.

-- 
Mark
"Any reference to 'goto' (an obscure Japanese admiral) are obscene, unfit for 
your eyes and anyway don't mean what you think they do" - University of 
Nottingham Maths department addendum to the Algol manual, circa 1975, 
paraphrased.

[toc] | [prev] | [next] | [standalone]

#41777

From	Thomas Koenig <tkoenig@netcologne.de>
Date	2014-03-13 21:09 +0000
Message-ID	<lft6qa$svi$1@newsreader4.netcologne.de>
In reply to	#41668

Stefan Ram <ram@zedat.fu-berlin.de> schrieb:

>   Is GOTO still considered harmful?

The most elegant control flow statement has to be the
AT statement (equivalent to COME FROM).

Consider the beauty of

      K = 3
  20  I = K

and, somewhere quite far from this,

      AT 20
      K = 5
      END

which sets K (and, in consequence I) to 5 but only when a
debug option is set.

Remove debugging, and your program does something quite different.

This was already in the Fortran G compiler, so it must be good ;-)

[toc] | [prev] | [next] | [standalone]

#41778

From	"Qolin" <noone@nowhere.com>
Date	2014-03-13 21:24 +0000
Message-ID	<lft7lu$2tf$1@dont-email.me>
In reply to	#41777

"Thomas Koenig"  wrote in message 
news:lft6qa$svi$1@newsreader4.netcologne.de...

> Stefan Ram <ram@zedat.fu-berlin.de> schrieb:
>
> >   Is GOTO still considered harmful?
>
> The most elegant control flow statement has to be the
> AT statement (equivalent to COME FROM).
>
> Consider the beauty of
>
>       K = 3
>   20  I = K
>
> and, somewhere quite far from this,
>
>       AT 20
>       K = 5
>       END
>
> which sets K (and, in consequence I) to 5 but only when a
> debug option is set.
>
> Remove debugging, and your program does something quite different.
>
> This was already in the Fortran G compiler, so it must be good ;-)

Reminds me of the COMEFROM statement...

Qolin

[toc] | [prev] | [next] | [standalone]

#41782

From	glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date	2014-03-13 22:36 +0000
Message-ID	<lftbsq$19v$1@speranza.aioe.org>
In reply to	#41778

In comp.lang.c Qolin <noone@nowhere.com> wrote:

> "Thomas Koenig"  wrote in message 
> news:lft6qa$svi$1@newsreader4.netcologne.de...

>> Stefan Ram <ram@zedat.fu-berlin.de> schrieb:

>> >   Is GOTO still considered harmful?

>> The most elegant control flow statement has to be the
>> AT statement (equivalent to COME FROM).

>> Consider the beauty of

>>       K = 3
>>   20  I = K

>> and, somewhere quite far from this,

>>       AT 20
>>       K = 5
>>       END

I did use the compiler, but I never tried this feature.
As well as I know it, you are supposed to use it, for example, to
print out values of variables, not change them. 

Under "Programming Considerations:"

  "3. An error in a program should not be corrected within a debug
      packet; when the packet is removed, the error remains in the
      progran."

There is a DISPLAY statement, which generates output similar to
NAMELIST, but without the need for a separate NAMELIST statement.
(Why didn't that ever make it in to the standard?)  As far as I can
tell, DISPLAY can only appear in a DEBUG packet. 

Seems that the idea is to put all debugging statements in one
place (just before END) making it easier to remove when the buts
are fixed.

DEC instead used a feature where lines starting with D were
comments, except when a compiler debugging option was used.
One should be able to quickly search for, and remove, such lines
once debugging was done.

>es  which sets K (and, in consequence I) to 5 but only when a
>> debug option is set.
>> Remove debugging, and your program does something quite different.
>> This was already in the Fortran G compiler, so it must be good ;-)

> Reminds me of the COMEFROM statement...

Stories are that COMEFROM was once added to a PL/I compiler, I
don't know about any Fortran compilers.  

Especially interesting for Fortran would be the computed COMEFROM
statement.

-- glen

[toc] | [prev] | [next] | [standalone]

#41791

From	Robert Wessel <robertwessel2@yahoo.com>
Date	2014-03-13 23:02 -0500
Message-ID	<0lv4i95qk7qttjoia83k8hoditjpb3gh4o@4ax.com>
In reply to	#41782

On Thu, 13 Mar 2014 22:36:10 +0000 (UTC), glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

>In comp.lang.c Qolin <noone@nowhere.com> wrote:
> 
>> "Thomas Koenig"  wrote in message 
>> news:lft6qa$svi$1@newsreader4.netcologne.de...
> 
>>> Stefan Ram <ram@zedat.fu-berlin.de> schrieb:
>
>>> >   Is GOTO still considered harmful?
>
>>> The most elegant control flow statement has to be the
>>> AT statement (equivalent to COME FROM).
>
>>> Consider the beauty of
>
>>>       K = 3
>>>   20  I = K
>
>>> and, somewhere quite far from this,
>
>>>       AT 20
>>>       K = 5
>>>       END
>
>I did use the compiler, but I never tried this feature.
>As well as I know it, you are supposed to use it, for example, to
>print out values of variables, not change them. 
>
>Under "Programming Considerations:"
>
>  "3. An error in a program should not be corrected within a debug
>      packet; when the packet is removed, the error remains in the
>      progran."
>
>There is a DISPLAY statement, which generates output similar to
>NAMELIST, but without the need for a separate NAMELIST statement.
>(Why didn't that ever make it in to the standard?)  As far as I can
>tell, DISPLAY can only appear in a DEBUG packet. 
>
>Seems that the idea is to put all debugging statements in one
>place (just before END) making it easier to remove when the buts
>are fixed.
>
>DEC instead used a feature where lines starting with D were
>comments, except when a compiler debugging option was used.
>One should be able to quickly search for, and remove, such lines
>once debugging was done.
>
>>es  which sets K (and, in consequence I) to 5 but only when a
>>> debug option is set.
>>> Remove debugging, and your program does something quite different.
>>> This was already in the Fortran G compiler, so it must be good ;-)
> 
>> Reminds me of the COMEFROM statement...
>
>Stories are that COMEFROM was once added to a PL/I compiler, I
>don't know about any Fortran compilers.  
>
>Especially interesting for Fortran would be the computed COMEFROM
>statement.


AFAIK, the COMEFROM "statement" was from a humorous Datamation article
published in the late 70s during much of the structure programming
debate.  Makes me miss the old "Fortran Man" cartoons in that
publication...

[toc] | [prev] | [next] | [standalone]

#41793

From	glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date	2014-03-14 04:07 +0000
Message-ID	<lftv99$79e$1@speranza.aioe.org>
In reply to	#41791

In comp.lang.c Robert Wessel <robertwessel2@yahoo.com> wrote:

(snip, I wrote)
>>Stories are that COMEFROM was once added to a PL/I compiler, I
>>don't know about any Fortran compilers.  

>>Especially interesting for Fortran would be the computed COMEFROM
>>statement.

> AFAIK, the COMEFROM "statement" was from a humorous Datamation article
> published in the late 70s during much of the structure programming
> debate.  Makes me miss the old "Fortran Man" cartoons in that
> publication...

When I was in high school, so about 1975, I used to sometimes
read Datamation in our city library. I think that is when I
saw the one about the PL/I compiler. 

-- glen

[toc] | [prev] | [next] | [standalone]

Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →

csiph-web

Is goto Still Considered Harmful?

Contents

#41872

#41876

#41912

#41731

#41684

#41707

#41710

#41719

#41721

#41741

#41753

#41745

#41747

#41720

#41755

#41777

#41778

#41782

#41791

#41793