[OT] [sdiy] IN your mind, what is ....

[Magnus Danielson]

From: "Michael E. Caloroso" <analoguediehard at att.net>
Subject: Re: [OT] [sdiy] IN your mind, what is ....
Date: Wed, 04 Feb 2004 10:08:57 -0500
Message-ID: <40210B09.6010306 at att.net>

> >>Not a simpler solution, but it keeps the pointer stack clean which is a
> >>goto cannot do.
> > 
> 
> Forbes, William - EE - UK/Leamington wrote:
>  > 'continue' and 'break' (except in a switch statement) are effectively
>  > goto's!
>  > The all cause a jump and the effects on maintainability can be just a
>  > severe as a goto!
>  > Why work round a 'goto' when a 'goto' is the most sensible thing to
>  > use?
> 
> Don Tillman wrote:
>  > If the operation you're doing is a naturally GOTO-like operation, what
>  > is so freaking horrible about implementing it with a GOTO instruction?
> 
> Rainer Buchty wrote:
> > A goto statement does *not* affect the stackpointer. It's the counterpart
> > to JMP/BRA in assembly language. All it does, is setting the program
> > counter. The stack pointer is influenced by gosub or, for that matter, any
> > function or procedure call.
> 
> Therein lies the crucial difference between goto and continue/break.
> 
> continue/break keep you *inside* the function.  This keeps the stack 
> clean as you will always encounter each RET call associated with its 
> GOSUB call.
> 
> goto statements can take you *outside* the function.  Do this and now 
> you have pointers in the stack that are invalid.  This fragments the 
> stack, raising the spectre of stack overflow and a system crash. 
> Framented memory is the bane of code that runs 24/7.

Indeed, but exiting the function you jumped to has a high risk of taking data
as the return PC and then the fragmented memory is the least of your worries.
Use of Frame-Pointers can avoid this, but it doesn't help much anyway.

Goto:s should NEVER be used to jump to a label in another function. Even if you
can make it "work" in one architecture, that may not work in another
architecture, since you depend on details in the calling-convention at the
best.

However, there is still NOTHING wrong about using goto within a function.
Using it with that restriction does nothing to the fragmentation of memory.
This is really the only real restriction. There is naturally other reasons on
why to be restrictive with gotos, such as clarity of code.

> I have done plenty of code optimization of legacy code.  Fragmented 
> memory is one of the worse offenders and is a topic that too few 
> developers are aware of.  Removing fragmented memory can extend code 
> MTBF from a few hours to weeks.

Yes, but the correct use of goto is within a function, and that can't result
in memory fragementation as such. However, fragmentation of memory is indeed a
problem and I agree that people don't spend much time to think about how they
use the memory they allocate directly or indirectly.

> Yes they may compile as JMP/BRA statements but it is the implementation 
> that is the difference.
> 
> WRT code reliability, that's a clearer way of doing it.  The political 
> correctiveness of eliminating goto's is irrelevant when the target 
> application is critical like medical monitoring apparatus or aerospace 
> controls.  If I ever set foot on a plane that contains some of my 
> design, you better believe I went the extra mile to confirm reliability 
> as the last place to encounter stack overflow/system crash is at 
> 30,000ft above ground.  That's what is so freaking horrible about a goto 
> statement.

I think you are overdoing it. Yes, the C goto is not sufficiently restricted,
but it should be. Sound use of it does not conflict with reliability, infact it
can in some cases actually contribute to it, by aiding to shape the code to a
clear structure.

Cheers,
Magnus